Re: On time64 and Large File Support
Paul Eggert <[email protected]> Fri, 11 Nov 2022 01:46:19 -0800
| Newsgroups | dev.linux.lists.c-std-porting |
|---|---|
| Organization | UCLA Computer Science Department |
| Message-ID | <[email protected]> |
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?