From: Junio C Hamano <gitster@pobox.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: git@vger.kernel.org, "David Aguilar" <davvid@gmail.com>,
"Randall S . Becker" <randall.becker@nexbridge.ca>,
"Taylor Blau" <me@ttaylorr.com>,
"Carlo Marcelo Arenas Belón" <carenas@gmail.com>,
"René Scharfe" <l.s.r@web.de>
Subject: Re: [PATCH v2] cache.h: auto-detect if zlib has uncompress2()
Date: Wed, 19 Jan 2022 11:17:08 -0800 [thread overview]
Message-ID: <xmqq1r13o7rf.fsf@gitster.g> (raw)
In-Reply-To: <patch-v2-1.1-444eacf30be-20220119T094428Z-avarab@gmail.com> ("Ævar Arnfjörð Bjarmason"'s message of "Wed, 19 Jan 2022 10:45:35 +0100")
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> Change the NO_UNCOMPRESS2=Y setting to auto-detect those older zlib
> versions that don't have uncompress2().
>
> This makes the compilation of git less annoying on older systems.
> Since the inclusion of a322920d0bb (Provide zlib's uncompress2 from
> compat/zlib-compat.c, 2021-10-07) in v2.35.0-rc0 our default
> dependency on a zlib 1.2.9 or newer, unless NO_UNCOMPRESS2=Y is
> specified. This results in new errors when git is compiled on older
> systems, requiring the packager to define NO_UNCOMPRESS2=Y.
>
> To get around those errors we've needed to bundle config.mak.uname
> changes such as 68d1da41c4e (build: NonStop ships with an older zlib,
> 2022-01-10), and ffb9f298090 (build: centos/RHEL 7 ships with an older
> gcc and zlib, 2022-01-15).
>
> Let's instead rely on ZLIB_VERNUM, as we in zlib.c already for
> NO_DEFLATE_BOUND. See 9da3acfb194 ([PATCH] compat: support pre-1.2
> zlib, 2005-04-30) and 609a2289d76 (Improve accuracy of check for
> presence of deflateBound., 2007-11-07) for that prior art.
> With this change it should be safe to remove the NO_UNCOMPRESS2=Y
> lines from config.mak.uname, but let's leave them in place for now.
It is not a big deal but I think removing is probably a more
sensible decision. If ZLIB_VERNUM does not misdetect for them, they
will not be harmed. And if it does, we'd rather hear from them
about the misdetection.
> Ideally we'd add compat/zlib-uncompress2.o to COMPAT_OBJS, but it's
> being added to our zlib.c instead. This is because we need to look at
> ZLIB_VERNUM to know if we need it. Hoisting that logic over to the
> Makefile would be inconvenient (we'd need shell out to "cc -E" or
> equivalent just to get the macro value). The zlib.c file already has
> the similar deflateBound() compatibility macro added in 9da3acfb194.
I am still unhappy about this part (meaning, I am happier about
everything else, compared to the previous iteration), that zlib.o
becomes mixture of our code and borrowed code.
The COMPAT mechanism have been that compat/foo.o is only compiled
and linked on a platform that lack foo and needs our replacement.
But in this case, I think the best would be to enclose the bulk of
zlib-uncompress2.c file inside a "#if ZLIB_VERNUM < ... #endif"
block and _always_ comiple and link the resulting zlib-uncompress2.o
file. We probably need to include a throw-away global symbol,
either a variable or a function, that is externally visible but
otherwise unused, to appease compilers linkers that do not want to
deal with an absolutely empty object file on platforms with a
working uncompress2() in their system zlib.
That way, we do not have to touch an unrelated file (zlib.c) for
this, which may be a lot cleaner.
> diff --git a/compat/zlib-uncompress2.c b/compat/zlib-uncompress2.c
> index 722610b9718..8592dc3dab5 100644
> --- a/compat/zlib-uncompress2.c
> +++ b/compat/zlib-uncompress2.c
> @@ -8,7 +8,6 @@
>
> */
>
> -#include "../reftable/system.h"
> #define z_const
>
> /*
> diff --git a/git-compat-util.h b/git-compat-util.h
> index 1229c8296b9..0c5e373e917 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -1386,6 +1386,13 @@ void unleak_memory(const void *ptr, size_t len);
> #define UNLEAK(var) do {} while (0)
> #endif
>
> +#if defined(NO_UNCOMPRESS2) || ZLIB_VERNUM < 0x1290
> +#include <zlib.h>
> +#define GIT_NO_UNCOMPRESS2 1
> +int uncompress2(Bytef *dest, uLongf *destLen, const Bytef *source,
> + uLong *sourceLen);
> +#endif
It is odd that we did not include <zlib.h> in this file, as the
design goal of git-compat-util.h is to free individual sources from
having to worry about order of inclusion and proprocessor symbols we
need to define before including certain system headers, etc. (for
example, defining z_const before including <zlib.h> would change the
"behaviour" of <zlib.h> header).
We are including <zlib.h> in <cache.h>, way after including the
<git-compat-util.h> file. I have a feeling that it may become
cleaner (and more correct) if we unconditionally include <zlib.h>
*BEFORE* we check ZLIB_VERNUM here, and lost the inclusion of
<zlib.h> from <cache.h>. With the posted patch, where are we
getting ZLIB_VERNUM from, which is used to decide if we declare
uncompress2() ourselves here?
next prev parent reply other threads:[~2022-01-19 19:17 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-17 17:13 [PATCH] cache.h: auto-detect if zlib has uncompress2() Ævar Arnfjörð Bjarmason
2022-01-17 18:27 ` Junio C Hamano
2022-01-17 18:48 ` rsbecker
2022-01-17 19:49 ` René Scharfe
2022-01-20 2:43 ` Carlo Arenas
2022-01-19 9:45 ` [PATCH v2] " Ævar Arnfjörð Bjarmason
2022-01-19 19:17 ` Junio C Hamano [this message]
2022-01-20 1:16 ` [PATCH v3] " Ævar Arnfjörð Bjarmason
2022-01-21 23:23 ` Junio C Hamano
2022-01-21 23:44 ` rsbecker
2022-01-22 0:55 ` Junio C Hamano
2022-01-23 0:19 ` Beat Bolli
2022-01-23 19:18 ` Junio C Hamano
2022-01-24 2:54 ` [PATCH v4] compat: " Junio C Hamano
2022-01-24 9:27 ` Ævar Arnfjörð Bjarmason
2022-01-24 18:27 ` [PATCH v5] " Junio C Hamano
2022-01-24 19:07 ` Ævar Arnfjörð Bjarmason
2022-01-24 20:21 ` Junio C Hamano
2022-01-25 10:11 ` Carlo Arenas
2022-01-25 18:11 ` Junio C Hamano
2022-01-25 19:12 ` Ævar Arnfjörð Bjarmason
2022-01-26 7:23 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqq1r13o7rf.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=avarab@gmail.com \
--cc=carenas@gmail.com \
--cc=davvid@gmail.com \
--cc=git@vger.kernel.org \
--cc=l.s.r@web.de \
--cc=me@ttaylorr.com \
--cc=randall.becker@nexbridge.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).