Hi all, In Gentoo, we've been planning out what we should do for time64 on glibc [0] and concluded that we need some support in glibc for a newer option. I'll outline why below. Proposal: glibc gains two new build-time configure options: * --enable-hard-time64 * --enable-hard-lfs These would hard-enable the relevant #defines within glibc's headers and ensure that any binaries built with such a glibc have both Large File Support (LFS) and time64 support. I've come to the conclusion it's infeasible to try handle the migration piecemeal. Various mismatches can and will occur (and while it's more likely with time64, it's possible with LFS too) [1]. We're now (possibly) on the eve of an autoconf 2.72 release which contains two changes of note [2][3] 1. addition of a new AC_SYS_YEAR2038 macro; 2. making AC_SYS_LARGEFILE change behaviour to imply AC_SYS_YEAR2038. Indeed, the gnulib version of change #2 is exactly how we ended up with wget/gnutls breaking [1]. I feel this shows that the only approach "supported" by glibc right now is untenable. On reflection and after extensive discussion within Gentoo (although I don't seek to speak for everybody there) - with special thanks to David Seifert and Arsen Arsenović for tolerating my bikesheds on this, we don't think it's feasible to handle this in a piecemeal fashion - at the very least not without spending a significant & for some, undesirable amount of time on supporting "obsolete" 32-bit platforms. Right now, we're forcing the year2038 autoconf cache variable off to avoid more gnutls/wget instances and plan to do a hard-rebuild (new set of "profiles" in Gentoo parlance) for 32-bit systems that enable this. This will be difficult to do properly without having significant stragglers without some support in glibc as proposed. All that to say, I don't propose making these options unconditional, because I think the boat has sailed as of glibc-2.34 [4], and I think it's fair that autoconf keep the behaviour as described in git master right now given the situation with glibc, but I don't think it's a wise path for most distributions to follow. See also a previous discussion on libc-alpha [5]. What do you think? [0] https://wiki.gentoo.org/wiki/Project:Toolchain/time64_migration [1] https://bugs.gentoo.org/828001 [2] https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=f6657256a37da44c987c04bf9cd75575dfca3b60 [3] https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=bc66c26f488975ea9ad22033b9fa28809f4bf65e [4] https://sourceware.org/pipermail/libc-alpha/2021-August/129718.html [5] https://sourceware.org/pipermail/libc-alpha/2022-January/134985.html best, sam
Attachment:
signature.asc
Description: Message signed with OpenPGP
