On 2026-09-01 11:45, Bruno Haible via GNU gzip discussion and bug reports. wrote:
Building it on bi-arch machines in 32-bit mode, the 'timestamp' test may fail.Find attached the logs of the builds on - Linux (Debian 8)/s390x, CC="gcc -m31",
Thanks for reporting this. I can't reproduce this on cfarm191, which runs Debian 13.6/s390x. As Debian 8 is no longer supported, I wouldn't worry about this issue for that old platform.
- Solaris 11.4/x86_64, CC="gcc -m32". In the Solaris 11.4 case, gzip prints a diagnostic gzip: in: Value too large for defined data type
I can reproduce this on Fedora x86-64 by running "./configure CC='cc -m32' --disable-year2038", and I fixed the problem there by installing the attached, which alters the test cases to not be so picky on these platforms.
From 06d45f8c475eee92206290bc929798b342083966 Mon Sep 17 00:00:00 2001 From: Paul Eggert <[email protected]> Date: Tue, 1 Sep 2026 21:57:02 -0700 Subject: [PATCH] tests: port timestamp tests to Solaris x86 Problem reported by Bruno Haible (Bug#81766). * tests/timestamp: Accept test results if time_t is 32 bits but 'touch' supports 64 bits. --- tests/timestamp | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/tests/timestamp b/tests/timestamp index ab1ca50..aa6ce31 100755 --- a/tests/timestamp +++ b/tests/timestamp @@ -39,7 +39,11 @@ do if touch -t $time in; then ls_l=$(ls -l in) case $ls_l in - *"$date"*) returns_ 2 gzip in || fail=1;; + *"$date"*) + # Warnings are exit status 2. Exit status 1 can occur + # if 'touch' supports 64-bit time_t but + # gzip was compiled with 32-bit time_t. + gzip in && fail=1;; esac fi rm -f in.gz in @@ -60,7 +64,12 @@ do if touch -t $time in; then ls_l=$(ls -l in) case $ls_l in - *"$date"*) gzip in || fail=1;; + *"$date"*) + gzip in + # Warnings are exit status 2. Exit status 1 can occur + # if 'touch' supports 64-bit time_t but + # gzip was compiled with 32-bit time_t. + test $? -eq 2 && fail=1;; esac fi rm -f in.gz in -- 2.53.0
