* Paul Eggert: > 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.) Ugh. >> 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. There are many documented toolchain features that change ABI. It's up to developers to determine whether it's safe to enable them. For Y2038 support, that's obviously quite desirable in principle. But we (glibc upstream) looked at it and concluded that we just can't introduce it by default and maintain backwards compatibility with existing binaries, which is of paramount importance for i386. I never expected GNU to switch i386 to time64 by default. Attempting this switch is a huge distraction and prevents many of us from working on more important matters that benefit GNU in much more direct ways. > 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? I don't know yet. Fortunately, any issues should be quite visibile in the distribution DWARF data. If we put the time32 switch in place, we should be able to tell whether it's effective enough in practice. > 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? LFS issues have been with us for a long time, and packages and distributions have workarounds for it (e.g., using off64_t or long long in public headers). What we have today mostly works. But it's unknown whether existing AC_SYS_LARGEFILE users require any additional work for time64 changes. It's also not clear how to approach this from an individual upstream perspective if different distributions have different requirements. I just don't see many libraries adopting a dual-ABI approach like glibc did, or spending much work on this. Thanks, Florian
