time_t. is 32-bit and is subject to the Y2038 problem. glibc 2.34 onwards supports opting-in to a 64-bit
time_t which allows handling time beyond Y2038.
This page discusses how to handle the migration for (32-bit) systems affected by this, including non-glibc environments. 64-bit systems are not affected.
time_t and 64-bit
time_t is a recipe for disaster where
time_t is exposed in a public API and the consumer/provider are mismatched e.g. net-misc/wget with net-libs/gnutls in bug #828001. This is actually
a problem with Large File Support (LFS) too but it seems to happen far less frequently there, or it was minimised by LARGEFILE_SOURCE allowing dual ABI in packages.
For 32-bit arches, we need to coordinate flipping glibc systems over to use 64-bit
CPPFLAGS="-D_TIME_BITS=64" (note that not all packages may support/respect
CPPFLAGS). Again, 64-bit arches are already fine.
Notes in no particular order:
- Support is new in glibc 2.34, stabled in April 2022 in bug #833191
- See discussion on libc-alpha here.
- Our friends in opensuse are on it too (https://www.reddit.com/r/linux/comments/xjtf3q/in_the_year_2038/)
- Gentoo's tracker bug: bug #876883
- See discussion on libc-alpha ("On time64 and Large File Support")
- Implement LFS and time64 QA check for Portage
- bug #549092
- Rebased version of LFS check at https://github.com/thesamesam/portage/blob/wip/bin/install-qa-check.d/10large-file-support
- Draft version of time64 check at https://github.com/thesamesam/portage/blob/wip/bin/install-qa-check.d/95time64_t
- Backport autoconf commit from master to make
AC_SYS_LARGEFILEimply 64-bit time_t
- How do we safely recommend rebuilding?
- Start with (some subset of?) @system then @world?
- How do we identify mismatched systems (possibly musl)? Will they just need to follow the glibc procedure we decide on (sans flags)?
- musl upstream already migrated to pure 64-bit
- Upstream notes
- Need to check how/if at all we handled it in Gentoo
- Check whether there's more work to be done to ensure user systems are in a consistent state
- 1.2.0 was added on 2020-02-25 and 1.2.1 (first of 1.2.x) was stabled on 2020-08-20.
- Possible user systems are in an inconsistent state given we've not rebuilt / news item'd for this?
- We may want to compare with how Large File Support (LFS) /
FILE_OFFSET_BITShas been handled
- Much more mature support
- bug #471102 tracks progress in Gentoo
- Meson already adds this as required
- autoconf has
AC_SYS_LARGEFILEwhich things should be using (but may not be!)
- We have
filter-lfs-flags) in flag-o-matic.eclass
Rebuild after profile change
This would need adjustment for the autoconf cache variable
ac_cv_type_time_t_y2038as well if/when we backport the upstream commit for AC_SYS_LARGEFILE.
- In current profiles, set
gl_cv_type_time_t_bits_macro=noto prevent gnulib autoconf macro from automatically adding
- In new profile, add
CPPFLAGS="-D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64"(do CFLAGS instead given insufficient packages respect CPPFLAGS).
- Advise users to adjust custom
CPPFLAGSif necessary, and rebuild @world after switching profiles.
Not everyone is using autoconf or even passing flags correctly. A safer, though probably more controversial way would be to force changed defaults in gcc and glibc.
- In packages where
time_tis utilized, revbump and add
append-cppflags -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64.
- This doesn't ensure that libraries and their consumers get rebuilt together, but it should work out in the end.
- Presumably, we'd have a large package.mask for this.
time64 USE flag
- May need lots of eautoreconf (after patching autoconf)
- Lots of --enable-year2038 added to econfs
- Unmask on to-be-created features/time64 profile
- Allows expressing dependencies on time64ness to help rebuild order
- Allows adding machinery to ebuilds at our own pace, then create new profiles when ready
- Doesn't cause churn to 64-bit arches
|Solution||Consistency during migration||Minimises disruption to bystander/unaffected users (64-bit arches)||Amount of manual labor needed||Avoids flag day|
|Rebuild after profile change (just changes cache variables)||Provides no guarantees of correct rebuild order and may require several rebuilds to ensure consistent ABI.||The change is invisible to these users as they already have 64-bit support and won't be changing profiles.||Not much at all.||No|
|Revbump ebuilds to add time64 CFLAGS||Provides no guarantees of correct rebuild order and may require several rebuilds to ensure consistent ABI.||All users, even those unaffected, have to rebuild.||Lots of ebuild churn.||We can make the changes gradually, by traversing leaf packages, and building up to libraries.|
|time64 USE flag||If dependencies are expressed correctly, we can ensure libraries gain time64 support before consumers, and we can use use= deps to enforce correctness.|| The USE flag will be masked on irrelevant profiles so only
||A lot of work modifying many ebuilds, especially if we're going to get the dependencies right, which is the advantage from this option...||We'd need a flag day to one day remove the time64 flag, but not just to add it.|