Proposed CHOST change for the 64bit time_t transition

[Michał Górny]

Hello,

On Thu, 2024-09-05 at 03:06 +0100, Wookey wrote:
> So it's interesting that in fact Gentoo _does_ want to do this, but it
> seems to me that this is now a done deal, and 'everyone' has already
> switched within the existing triplets, even Debian, which is the
> hardest place to do this because it involved 1100 library transitions,
> with another 3500-odd rebuilds.

I disagree with this claim, and I really feel like in this whole thread
people are underestimating the gravity of this situation.

In the case of Gentoo, being a source distribution implies that
the vast majority of users are building everything from source.  While
binary packages are supported to some degree, this is not something we
can rely on.  As such, we need to assume that the transition will
involve rebuilding everything from source.

This in turn implies rebuilding whole production systems, bottom up. 
This means that there will be significant periods of time during which
production systems will be running with ABI incompatibilities between
programs and their dependent libraries, and these periods will be much
longer than if binary packages were used.  In other words, production
systems will be quasi-broken for extended period of time.

What's even more dangerous is that any particular rebuild can actually
fail -- and then the user may suddenly be left with a quasi-broken
system, pending urgent recovery.  I mean, just imagine that one of your
dependent libraries failed to rebuild, and you end up having a 32-bit
time_t program with some of its dependencies using 32-bit time_t,
and others 64-bit time_t already -- and you suddenly have to figure out
how to make the problematic package build again, or revert everything
back.

Now, I'm not an expert on ABI but I do believe that the potential for
breakage is pretty serious.  After all, we are talking about doubling
the type size.  So we're talking about function parameters being
shifted, struct offset mismatches, stack corruption, heap corruption...

I think it does make sense to clearly indicate that this is a serious
change of ABI.  Furthermore, I personally would even go as far as to
change libdir, as to ensure that we can rebuild everything without
immediately breaking production systems in place.

On top of that, we need to account for the fact that users may have some
executables that they've compiled and linked to the system libraries
themselves, and these also may start suddenly misbehaving.  So perhaps
the right thing is to ensure that you can't even run an executable
unless all its linked libraries use the same time_t variant.

-- 
Best regards,
Michał Górny

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 512 bytes
Desc: This is a digitally signed message part
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20240907/037b4b1c/attachment.sig>