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