* Sam James: > 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 We should define new target triplets for this if it's really required. We need to support legacy binaries on i386. Few libraries are explicitly dual-ABI. Whether it's safe to switch libraries above glibc to LFS or time64 needs to be evaluated on a per-library basis. For most distributions, no one is going to do that work, and we have to stick to whathever we are building today. > 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. AC_SYS_LARGEFILE defaulting to AC_SYS_YEAR2038 is extremely destructive for Fedora unfortunately. I thought the gnulib change has been reverted? 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. > 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. Fedora will have to implement some sort of override as well. We can't do a hard rebuild because of compatibility requirements. There are old binaries people still use, and contemporary binaries built on relatively current distributions (distributions that will never switch i386 ABI). > 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. Hopefully the autoconf change can still be reverted. Thanks, Florian
