Re: tests/time01.at failing on i586, ppc and armv7l

[Paul Eggert]

On 10/13/21 13:57, Bernhard Voelker wrote:

> Is it possible that newer touch(1) from coreutils-9.0 supports more of the 
> tricky timestamps
> which tar-1.34 still fails to grok?


I guess that coreutils was built with 64-bit time_t, but the compiler or 
development library for some reason doesn't support 64-bit time_t. 
Perhaps a coreutils/glibc mismatch? You'll need glibc 2.34 or later on 
platforms like i586 where time_t is traditionally 32-bit but recent 
Linux kernels have support for 64-bit time_t (this is true for 32-bit 
x86 and ARM; I don't know about 32-bit PPC).

To pass the tests you can build on a 32-bit-only system, with a 
coreutils that does not support 64-bit time_t, so that the 'tar' tests 
don't attempt to try file timestamps past the year 2038.

I suppose we could modify GNU tar's tests so that it doesn't attempt to 
try these post-2038 timestamps on 32-bit builds. However, it might be 
better to leave those tests alone, to remind people to be wary of 
building 32-bit time_t apps with the clock ticking away towards the year 
2038 (when these apps will stop working).

Since GNU tar is a core GNU app, I expect that it should use the same 
year2038 module that coreutils does, to underscore the importance of 
being year-2038 safe. So I added the year2038 module to the 
gnulib.modules files of paxutils and tar on Savannah. If you build from 
bleeding-edge tar and don't want 64-bit time_t, you can configure with 
--disable-year2038 (though the tests you mention will still fail if 
coreutils is 64-bit).