Re: On time64 and Large File Support

[Paul Eggert <eggert@cs.ucla.edu>]

On 2022-11-11 01:19, Florian Weimer wrote:

> AC_SYS_LARGEFILE defaulting to AC_SYS_YEAR2038 is extremely destructive
> for Fedora unfortunately.
> 
> I thought the gnulib change has been reverted?

I'm not sure where you got that impression. Bleeding-edge (unreleased) 
Autoconf AC_SYS_LARGEFILE, along with Gnulib AS_SYS_LARGEFILE as shipped 
in several GNU apps already, default to 64-bit time_t on platforms where 
setting _TIME_BITS=64 changes time_t from 32 to 64 bits.  (This is not 
the same as defaulting to AC_SYS_YEAR2038 which *requires* 
wider-than-32-bit time_t, but I expect the difference doesn't matter here.)


> I really wish the rest of GNU would talk to glibc maintainers before
> overriding glibc maintainer decisions.  If we cannot revert this in
> autoconf (and gnulib), this will very much endanger the Fedora i386
> port.  Debian will probably be impacted in the same way.

I'm not sure what is meant by "overriding", as Autoconf etc. are merely 
using a documented glibc feature. Also, the apps in question can be 
configured to stick with 32-bit time_t by using "./configure 
--disable-year2038" and/or setting the corresponding cache variables, so 
distros continue to have a choice about which time_t flavor they prefer.

What I'm gathering from your email is that 32-bit Fedora x86 needs an 
easy way to say "hold on, I want 32-bit time_t to be the default for all 
'configure' runs". If the --disable-year2038 option of 'configure' isn't 
enough, and/or setting the appropriate cache variables isn't enough, 
what other configuration method would you like?

Also, how does this issue with 64-bit time_t differ from the decades-old 
issue with 64-bit off_t? AC_SYS_LARGEFILE has long defaulted to 64-bit 
off_t, and Autoconf-generated configure scripts have long had 
--disable-largefile options and related cache variables much the same 
way that they're now dealing with 64-bit time_t. Is the difference 
merely that time_t is more widely used than off_t, so the ABI problems 
are more likely now?