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?
