Project:Toolchain/time64 migration

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.

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

Obviously 64-bit arches are already fine.

Notes in no particular order:
 * Support is new in glibc 2.34 which is still in ~arch, not stable.

See discussion on libc-alpha here too.

TODO

 * 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)?
 * Backport autoconf commit from master to make  imply 64-bit time_t

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 very little respects 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.