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?
