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
* 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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.