Project:Toolchain/time64 migration

From Gentoo Wiki
Jump to:navigation Jump to:search

Traditional 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.

Mixing 32-bit 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 time_t using 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:




  • musl upstream already migrated to pure 64-bit time_t in 1.2.0
  • 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_BITS has been handled
  • Much more mature support
  • bug #471102 tracks progress in Gentoo
  • Meson already adds this as required
  • autoconf has AC_SYS_LARGEFILE which things should be using (but may not be!)
  • We have append-lfs-flags (and filter-lfs-flags) in flag-o-matic.eclass

Possible solutions

Rebuild after profile change

This would need adjustment for the autoconf cache variable ac_cv_type_time_t_y2038 as well if/when we backport the upstream commit for AC_SYS_LARGEFILE.
  • In current profiles, set gl_cv_type_time_t_bits_macro=no to prevent gnulib autoconf macro from automatically adding -D_TIME_BITS=64 (done)
  • 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 CPPFLAGS if 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.

Revbump ebuilds

  • In packages where time_t is 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

  • Add USE=time64 masked everywhere
  • 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 --newuse (-N) users will be affected. 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.