Project:Toolchain/time64 migration

Traditional  is 32-bit and is subject to the Y2038 problem. glibc 2.34 onwards supports opting-in to a 64-bit  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  and 64-bit   is a recipe for disaster where   is exposed in a public API and the consumer/provider are mismatched e.g.  with  in. 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  using   (note that not all packages may support/respect  ). Again, 64-bit arches are already fine.

Problem
Sneaky bits:
 * 1) Libraries using time_t directly or indirectly needs to be switched at the same time. Applications using any such libraries must be switched at the same time too.
 * 2) Software might be using   (and e.g. , needing Large File Support (LFS)) without it being obvious. For example, it might be handling a   struct which contains both   and.
 * 3) Software needs to provide a way to stick with 32-bit   for now to avoid making the problem worse, but allow optionally using 64-bit
 * 4) We have to complete Modern C porting first to remove any instances of   otherwise the redirects in glibc for e.g. time->time64 won't actually work.

The core issues are:
 * 1) Auditing packages piecemeal is an unfeasibly large amount of work
 * 2) glibc has no mechanism to hard-switch yet (and discussion has stalled )
 * 3) Acting alone in a hard-switch (or at all, really) risks incompatibility with other distributions, as all of this obviously affects ABI
 * 4)   or  -dependent types in a library's API is not always straightforward to see

TODO

 * Push for an autoconf release which both fixes some Modern C porting issues and contains the needed macros for Y2038 support. The needed fixes are already in git.
 * Agree on a way with the upstream glibc + distro community on how to hard-switch glibc.
 * Coordinate hard-switching once (plenty of!) testing has been done

Gentoo-specific TODO items, but they may affect other distros too:
 * Implement LFS and time64 QA check for Portage
 * 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  imply 64-bit time_t (this got yanked upstream so no need to just accept it now)
 * 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)?
 * How do we identify mismatched systems (possibly musl)? Will they just need to follow the glibc procedure we decide on (sans flags)?

musl

 * musl upstream already migrated to pure 64-bit  in 1.2.0
 * Upstream have a detailed set of notes on the problem
 * Adélie Linux's time64 notes

Gentoo specific 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?

LFS
We may want to compare with how Large File Support (LFS) /  has been handled. Much more mature support overall in the ecosystem, although it wasn't generally treated like the ABI break it was.

Misc notes:
 * For glibc, time64 needs LFS (example of why: see e.g. stat struct).
 * Meson already adds this as required
 * autoconf has  which things should be using (but may not be!)

Gentoo specific notes:
 * tracks progress in Gentoo overall.
 * We have  (and  ) in flag-o-matic.eclass

Rebuild after profile change

 * In current profiles, set  to prevent gnulib autoconf macro from automatically adding   (done)
 * In new profile, add  (do CFLAGS instead given insufficient packages respect CPPFLAGS).
 * Advise users to adjust custom  if necessary, and rebuild @world after switching profiles.

Revbump ebuilds

 * In packages where  is utilized, revbump and add.
 * 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 for this.

time64 USE flag

 * Add  masked everywhere
 * May need lots of (after patching autoconf)
 * Lots of --enable-year2038 added to econfs
 * Unmask on to-be-created 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

External resources

 * Preparing for Y2038 (Already?!)
 * glibc is still not Y2038 compliant by default
 * Debian discusses how to handle 2038 (from 2020, outdated wrt glibc)