git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
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?




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