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
The core issue is:
 * 1) Auditing packages piecemeal is an unfeasibly large amount of work
 * 2) glibc has no mechanism to hard-switch yet (and discussion has stalled: https://sourceware.org/pipermail/libc-alpha/2022-November/143386.html).
 * 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

 * 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
 * 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 notes
 * Adélie Linux's time64 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
 * tracks progress in Gentoo
 * Meson already adds this as required
 * autoconf has  which things should be using (but may not be!)
 * 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