Re: [PATCH v2] cache.h: auto-detect if zlib has uncompress2()

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 19, 2022, 19:17 UTC
Message-ID: <xmqq1r13o7rf.fsf@gitster.g>
In-Reply-To: <patch-v2-1.1-444eacf30be-20220119T094428Z-avarab@gmail.com>

Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:

Show 19 quoted lines

> 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.

Show 6 quoted lines

> 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.

Show 26 quoted lines

> 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?