# [PATCH 0/2] Ensure zlib version is printed by git-version(1) 6 messages from 2025-03-07 to 2025-03-07. Participants: Toon Claes, Patrick Steinhardt, Junio C Hamano. Thread: https://gitlist.dev/t/63074 ## Toon Claes, 2025-03-07 14:18 Subject: [PATCH 0/2] Ensure zlib version is printed by git-version(1) Message-ID: <20250307-toon-zlib-git-version-v1-0-5e8069752bb9@iotcl.com> URL: https://gitlist.dev/e/20250307-toon-zlib-git-version-v1-0-5e8069752bb9%40iotcl.com ``` I was trying to benchmark the difference between using zlib and zlib-ng. To be sure I was testing the correct version, I was interested if git-version(1) would tell which zlib library it uses. After some digging I saw it should be printing the zlib version number, but on my machine it wasn't. I discovered a regression caused by 41f1a8435a (git-compat-util: move include of "compat/zlib.h" into "git-zlib.h", 2025-01-28). In the first commit I'm addressing that regression. But I've noticed building against zlib-ng directly still didn't print the zlib version. This issue is resolved in the second commit. -- Toon Signed-off-by: Toon Claes --- Toon Claes (2): help: include git-zlib.h to print zlib version help: print zlib-ng version number help.c | 5 ++++- t/t0091-bugreport.sh | 3 ++- 2 files changed, 6 insertions(+), 2 deletions(-) --- --- base-commit: a36e024e989f4d35f35987a60e3af8022cac3420 change-id: 20250307-toon-zlib-git-version-a7dcb9caa1ef Thanks -- Toon ``` ## Toon Claes, 2025-03-07 14:18 Subject: [PATCH 1/2] help: include git-zlib.h to print zlib version Message-ID: <20250307-toon-zlib-git-version-v1-1-5e8069752bb9@iotcl.com> URL: https://gitlist.dev/e/20250307-toon-zlib-git-version-v1-1-5e8069752bb9%40iotcl.com In-Reply-To: <20250307-toon-zlib-git-version-v1-0-5e8069752bb9@iotcl.com> ``` In 41f1a8435a (git-compat-util: move include of "compat/zlib.h" into "git-zlib.h", 2025-01-28) some code was refactored to enable easier linking against zlib-ng. This removed `zlib.h` being indirectly included in `help.c`. As this file uses `ZLIB_VERSION` to print the version number of zlib when running git-version(1) with `--build-options`, this resulted in a regression. Include `git-zlib.h` directly into `help.c` to print zlib version information. This brings back the zlib version in the output of `git version --build-options`. Signed-off-by: Toon Claes --- help.c | 1 + 1 file changed, 1 insertion(+) diff --git a/help.c b/help.c index 8d91afe851..707cd59b79 100644 --- a/help.c +++ b/help.c @@ -2,6 +2,7 @@ #define DISABLE_SIGN_COMPARE_WARNINGS #include "git-compat-util.h" +#include "git-zlib.h" #include "config.h" #include "builtin.h" #include "exec-cmd.h" -- 2.49.0.rc1.410.g72b47a15e9 ``` ## Toon Claes, 2025-03-07 14:18 Subject: [PATCH 2/2] help: print zlib-ng version number Message-ID: <20250307-toon-zlib-git-version-v1-2-5e8069752bb9@iotcl.com> URL: https://gitlist.dev/e/20250307-toon-zlib-git-version-v1-2-5e8069752bb9%40iotcl.com In-Reply-To: <20250307-toon-zlib-git-version-v1-0-5e8069752bb9@iotcl.com> ``` When building against zlib-ng, the header file `zlib.h` is not included, but `zlib-ng.h` is included instead. It's `zlib.h` that defines `ZLIB_VERSION` and that macro is used to print out zlib version in `git-version(1)` with `--build-options`. But when it's not defined, no version is printed. `zlib-ng.h` defines another macro: `ZLIBNG_VERSION`. Use that macro to print the zlib-ng version in `git version --build-options` when it's set. Otherwise fallback to `ZLIB_VERSION`. Signed-off-by: Toon Claes Helped-by: Patrick Steinhardt --- help.c | 4 +++- t/t0091-bugreport.sh | 3 ++- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/help.c b/help.c index 707cd59b79..c54bd9918a 100644 --- a/help.c +++ b/help.c @@ -798,7 +798,9 @@ void get_version_info(struct strbuf *buf, int show_build_options) #if defined OPENSSL_VERSION_TEXT strbuf_addf(buf, "OpenSSL: %s\n", OPENSSL_VERSION_TEXT); #endif -#if defined ZLIB_VERSION +#if defined ZLIBNG_VERSION + strbuf_addf(buf, "zlib-ng: %s\n", ZLIBNG_VERSION); +#elif defined ZLIB_VERSION strbuf_addf(buf, "zlib: %s\n", ZLIB_VERSION); #endif } diff --git a/t/t0091-bugreport.sh b/t/t0091-bugreport.sh index e11d819b62..e38ca7a901 100755 --- a/t/t0091-bugreport.sh +++ b/t/t0091-bugreport.sh @@ -47,7 +47,8 @@ test_expect_success 'sanity check "System Info" section' ' # This is bound to differ from environment to environment, # so we just do some rather high-level checks. grep "uname: ." system && - grep "compiler info: ." system + grep "compiler info: ." system && + grep "zlib." system ' test_expect_success 'dies if file with same name as report already exists' ' -- 2.49.0.rc1.410.g72b47a15e9 ``` ## Patrick Steinhardt, 2025-03-07 14:20 Subject: Re: [PATCH 0/2] Ensure zlib version is printed by git-version(1) Message-ID: URL: https://gitlist.dev/e/Z8sAwLHff3S4jF1P%40pks.im In-Reply-To: <20250307-toon-zlib-git-version-v1-0-5e8069752bb9@iotcl.com> ``` On Fri, Mar 07, 2025 at 03:18:06PM +0100, Toon Claes wrote: > I was trying to benchmark the difference between using zlib and zlib-ng. > To be sure I was testing the correct version, I was interested if > git-version(1) would tell which zlib library it uses. After some digging > I saw it should be printing the zlib version number, but on my machine > it wasn't. > > I discovered a regression caused by 41f1a8435a (git-compat-util: move > include of "compat/zlib.h" into "git-zlib.h", 2025-01-28). In the first > commit I'm addressing that regression. > > But I've noticed building against zlib-ng directly still didn't print > the zlib version. This issue is resolved in the second commit. I've already reviewed the change internally and it looked obviously good to me. Thanks for finding, fixing and improving this! Patrick ``` ## Junio C Hamano, 2025-03-07 20:25 Subject: Re: [PATCH 1/2] help: include git-zlib.h to print zlib version Message-ID: URL: https://gitlist.dev/e/xmqqbjucegg9.fsf%40gitster.g In-Reply-To: <20250307-toon-zlib-git-version-v1-1-5e8069752bb9@iotcl.com> ``` Toon Claes writes: > In 41f1a8435a (git-compat-util: move include of "compat/zlib.h" into > "git-zlib.h", 2025-01-28) some code was refactored to enable easier > linking against zlib-ng. > > This removed `zlib.h` being indirectly included in `help.c`. As this > file uses `ZLIB_VERSION` to print the version number of zlib when > running git-version(1) with `--build-options`, this resulted in a > regression. > > Include `git-zlib.h` directly into `help.c` to print zlib version > information. This brings back the zlib version in the output of > `git version --build-options`. > > Signed-off-by: Toon Claes > --- > help.c | 1 + > 1 file changed, 1 insertion(+) OK, the user was merely "#ifdef ZLIB_VERSION", so this new inclusion would not introduce a separate unintended breakage, I would think. Makes sense. Will queue. > diff --git a/help.c b/help.c > index 8d91afe851..707cd59b79 100644 > --- a/help.c > +++ b/help.c > @@ -2,6 +2,7 @@ > #define DISABLE_SIGN_COMPARE_WARNINGS > > #include "git-compat-util.h" > +#include "git-zlib.h" > #include "config.h" > #include "builtin.h" > #include "exec-cmd.h" ``` ## Junio C Hamano, 2025-03-07 20:25 Subject: Re: [PATCH 0/2] Ensure zlib version is printed by git-version(1) Message-ID: URL: https://gitlist.dev/e/xmqq7c50egfq.fsf%40gitster.g In-Reply-To: ``` Patrick Steinhardt writes: > On Fri, Mar 07, 2025 at 03:18:06PM +0100, Toon Claes wrote: >> I was trying to benchmark the difference between using zlib and zlib-ng. >> To be sure I was testing the correct version, I was interested if >> git-version(1) would tell which zlib library it uses. After some digging >> I saw it should be printing the zlib version number, but on my machine >> it wasn't. >> >> I discovered a regression caused by 41f1a8435a (git-compat-util: move >> include of "compat/zlib.h" into "git-zlib.h", 2025-01-28). In the first >> commit I'm addressing that regression. >> >> But I've noticed building against zlib-ng directly still didn't print >> the zlib version. This issue is resolved in the second commit. > > I've already reviewed the change internally and it looked obviously good > to me. Thanks for finding, fixing and improving this! Thanks, both. The changes look quite sensible. ```