git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "René Scharfe" <l.s.r@web.de>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>, git@vger.kernel.org
Cc: "Junio C Hamano" <gitster@pobox.com>,
	"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>
Subject: Re: [PATCH] cache.h: auto-detect if zlib has uncompress2()
Date: Mon, 17 Jan 2022 20:49:44 +0100	[thread overview]
Message-ID: <5c65baaa-ad51-e7e3-c811-1860edb7fff4@web.de> (raw)
In-Reply-To: <patch-1.1-9cea01a1395-20220117T170457Z-avarab@gmail.com>

Am 17.01.22 um 18:13 schrieb Ævar Arnfjörð Bjarmason:
> 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 has resulted in errors when git is compiled.
>
> To get around those errors we've needed to bundle config.mak.uname
> changes such as such as 68d1da41c4e (build: NonStop ships with an
> older zlib, 2022-01-10) and the in-flight
> https://lore.kernel.org/git/20220116020520.26895-1-davvid@gmail.com/.
>
> Let's instead rely on ZLIB_VERNUM. Now only those systems where zlib
> is so broken that it can't be rely on (such a system probably doesn't
> exist) need to provide a NO_UNCOMPRESS2=Y.
>
> 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 in-tree prior art using ZLIB_VERNUM.
>
> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
> ---
>
> I think this should be strongly considered for inclusion before the
> final v2.35.0 release.
>
> Aside from the ones already (and in-flight) in config.mak.uname, I've
> run into numerous other cases where NO_UNCOMPRESS2=y is needed (so far
> gcc{10,14,45,111,119,135,210} on the GCC farm). Adding
> config.mak.uname detections to those would be tedious, we'd need to
> start detecting various other OS versions.
>
> Or, we can just ask zlib.h abuot its ZLIB_VERSION instead, and include
> compat/zlib-uncompress2.c in our own zlib.c wrapper.
>
> This has an interaction with da/rhel7-lacks-uncompress2-and-c99 (the
> merge should preferably delete the NO_UNCOMPRESS2=Y it adds), it's in
> "next", but I didn't base this on that topic as "nex" clearly won't be
> merged down before v2.35.0.
>
>  Makefile                  |  6 ++++--
>  cache.h                   |  5 +++++
>  compat/zlib-uncompress2.c |  5 +----
>  config.mak.uname          |  6 ------
>  reftable/block.c          |  2 +-
>  reftable/system.h         | 12 +-----------
>  zlib.c                    |  3 +++
>  7 files changed, 15 insertions(+), 24 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 5580859afdb..3e90820bbfd 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -256,7 +256,10 @@ all::
>  #
>  # Define NO_DEFLATE_BOUND if your zlib does not have deflateBound.
>  #
> -# Define NO_UNCOMPRESS2 if your zlib does not have uncompress2.
> +# Define NO_UNCOMPRESS2 if your zlib is older than v1.2.9 and does not
> +# have uncompress2. You should not need to define this unless your
> +# zlib's ZLIB_VERNUM is broken. We'll auto-detect this on the basis of
> +# that macro.
>  #
>  # Define NO_NORETURN if using buggy versions of gcc 4.6+ and profile feedback,
>  # as the compiler can crash (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49299)
> @@ -1728,7 +1731,6 @@ endif
>
>  ifdef NO_UNCOMPRESS2
>  	BASIC_CFLAGS += -DNO_UNCOMPRESS2
> -	REFTABLE_OBJS += compat/zlib-uncompress2.o
>  endif
>
>  ifdef NO_POSIX_GOODIES
> diff --git a/cache.h b/cache.h
> index 281f00ab1b1..02b355fcf08 100644
> --- a/cache.h
> +++ b/cache.h
> @@ -29,6 +29,11 @@ typedef struct git_zstream {
>  	unsigned char *next_out;
>  } git_zstream;
>
> +#if defined(NO_UNCOMPRESS2) || ZLIB_VERNUM < 0x1290
> +#define GIT_NO_UNCOMPRESS2 1
> +int uncompress2(Bytef *dest, uLongf *destLen, const Bytef *source,
> +		uLong *sourceLen);
> +#endif
>  void git_inflate_init(git_zstream *);
>  void git_inflate_init_gzip_only(git_zstream *);
>  void git_inflate_end(git_zstream *);
> diff --git a/compat/zlib-uncompress2.c b/compat/zlib-uncompress2.c
> index 722610b9718..915796e85ac 100644
> --- a/compat/zlib-uncompress2.c
> +++ b/compat/zlib-uncompress2.c
> @@ -8,15 +8,12 @@
>
>  */
>
> -#include "../reftable/system.h"
> -#define z_const

Why is it safe to remove this definition?  Because it's defined in
zconf.h, included by zlib.h.  But why did we need it in the first place?
Not caused by this patch, of course, but still strange.

> -
>  /*
>   * Copyright (C) 1995-2003, 2010, 2014, 2016 Jean-loup Gailly, Mark Adler
>   * For conditions of distribution and use, see copyright notice in zlib.h
>   */
>
> -#include <zlib.h>
> +/* No "#include <zlib.h>", done in cache.h */

Well, it's rather something like "No #include, period.  Because this
file is not meant to be compiled on its own, but is included itself.",
isn't it?

>
>  /* clang-format off */
>
> diff --git a/config.mak.uname b/config.mak.uname
> index 9b3e9bff5f5..d0701f9beb0 100644
> --- a/config.mak.uname
> +++ b/config.mak.uname
> @@ -261,10 +261,6 @@ ifeq ($(uname_S),FreeBSD)
>  	FILENO_IS_A_MACRO = UnfortunatelyYes
>  endif
>  ifeq ($(uname_S),OpenBSD)
> -	# Versions < 7.0 need compatibility layer
> -	ifeq ($(shell expr "$(uname_R)" : "[1-6]\."),2)
> -		NO_UNCOMPRESS2 = UnfortunatelyYes
> -	endif

No longer relying on OS version trivia like this is very nice.

>  	NO_STRCASESTR = YesPlease
>  	NO_MEMMEM = YesPlease
>  	USE_ST_TIMESPEC = YesPlease
> @@ -520,7 +516,6 @@ ifeq ($(uname_S),Interix)
>  	endif
>  endif
>  ifeq ($(uname_S),Minix)
> -	NO_UNCOMPRESS2 = YesPlease
>  	NO_IPV6 = YesPlease
>  	NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease
>  	NO_NSEC = YesPlease
> @@ -576,7 +571,6 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
>  	NO_SETENV = YesPlease
>  	NO_UNSETENV = YesPlease
>  	NO_MKDTEMP = YesPlease
> -	NO_UNCOMPRESS2 = YesPlease
>  	# Currently libiconv-1.9.1.
>  	OLD_ICONV = UnfortunatelyYes
>  	NO_REGEX = NeedsStartEnd
> diff --git a/reftable/block.c b/reftable/block.c
> index 855e3f5c947..946edd0f34e 100644
> --- a/reftable/block.c
> +++ b/reftable/block.c
> @@ -13,7 +13,7 @@ license that can be found in the LICENSE file or at
>  #include "record.h"
>  #include "reftable-error.h"
>  #include "system.h"
> -#include <zlib.h>
> +#include "zlib.h"

Why?  We don't have a local zlib.h and this patch doesn't add one.

And don't you need to rather include cache.h, to get the definition
of uncompress2 on systems that don't have it in their zlib.h?

>
>  int header_size(int version)
>  {
> diff --git a/reftable/system.h b/reftable/system.h
> index 4907306c0c5..2cebbc94d4d 100644
> --- a/reftable/system.h
> +++ b/reftable/system.h
> @@ -15,17 +15,7 @@ license that can be found in the LICENSE file or at
>  #include "strbuf.h"
>  #include "hash.h" /* hash ID, sizes.*/
>  #include "dir.h" /* remove_dir_recursively, for tests.*/
> -
> -#include <zlib.h>
> -
> -#ifdef NO_UNCOMPRESS2
> -/*
> - * This is uncompress2, which is only available in zlib >= 1.2.9
> - * (released as of early 2017)
> - */
> -int uncompress2(Bytef *dest, uLongf *destLen, const Bytef *source,
> -		uLong *sourceLen);
> -#endif
> +#include "zlib.h"

Same here.  Or rather: Just here.  The include in reftable/block.c
can be removed safely, because it includes this reftable/system.h
here anyway.

>
>  int hash_size(uint32_t id);
>
> diff --git a/zlib.c b/zlib.c
> index d594cba3fc9..d9440dfb784 100644
> --- a/zlib.c
> +++ b/zlib.c
> @@ -3,6 +3,9 @@
>   * at init time.
>   */
>  #include "cache.h"
> +#ifdef GIT_NO_UNCOMPRESS2
> +#include "compat/zlib-uncompress2.c"
> +#endif

Keeping the function definition in its own file in compat/ with its
own license note is a good choice for maintainability, I think.

>
>  static const char *zerr_to_string(int status)
>  {


  parent reply	other threads:[~2022-01-17 19:49 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 [this message]
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
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=5c65baaa-ad51-e7e3-c811-1860edb7fff4@web.de \
    --to=l.s.r@web.de \
    --cc=avarab@gmail.com \
    --cc=carenas@gmail.com \
    --cc=davvid@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --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).