Re: Proposed CHOST change for the 64bit time_t transition

[Wookey]

On 2024-09-04 17:48 +0200, Andreas K. Huettel wrote:
> Dear all, 
> 
> in Gentoo Linux we want to change our CHOST triplets for 32-bit glibc systems 
> that use 64-bit time_t, since
> this is technically an ABI change which breaks binary compatibility [1].

> * In an ideal world this change would be synchronized across distributions. 
> Opinions? [5]

Debian considered this issue over the last 18 months/2 years, and
found very little enthusiasm for making new triplets. Every distro
that is using 64-bit time (on 32-bit arches) just enabled the flags
and changed the ABI without setting a new arch/triplet (or they have
dropped 32-bit stuff entirely so sidestepped the issue).

Given this, and because users would like to just be upgraded to 64-bit
time, not have to install a new architecture, Debian and Ubuntu
decided not to try and push a new triplet and do a library-name ABI
update within the architecture(s). That went ahead between March and
June this year and is now pretty-much done, modulo a few outstanding
bugs
(https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-arm@lists.debian.org;tag=time-t).

Debian's thinking and status is summarised here: 
https://wiki.debian.org/ReleaseGoals/64bit-time

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.

> [1] The ABI of glibc does technically NOT change, however, the type 
> definition of, e.g., time_t does.
>     And as soon as any other library includes that in its public interfaces 
> and data structures, that library
>     changes its ABI.
>     An example for an affected library (found real-world during testing) is 
> gnutls, see 
>     https://bugs.gentoo.org/828001

Yes. We did a big ABI analysis to find out how many libraries were
affected (including LFS which glibc ties into this transition) and it
was about 700. (there were quite a few more where the automated ABI
tools failed and it was easier to do a transition than work out why,
so we ended up transitioning 1093 source packages
(https://people.canonical.com/~vorlon/armhf-time_t/source-packages).

So yes it's an ABI change, but we don't always change the triplet for
this, sometimes we just move the baseline along. This happened in the
last for glibc 5->6 and libstdc++ v4 to v5 and the long-double
redefinition in s390,alpha, sparc, powerpc. In fact, considering the
whole-distro collective ABI, this happens every time there is an ABI
change in a library. The arch/triplet remains the same, but the new
release has a different ABI in some number of libraries and
dependencies.

So it's always a choice whether the triplet should change or it is
just treated as an update, and usually the latter is chosen. This was
a borderline case that could have gone either way, but people decided
to do it as a transition, not a new triplet.

Are you sure gentoo will gain enough value from going it alone here
and defining a new triplet? Because every other distro will have (has
already got in fact) the t64 ABI with the old triplet.


> [2] We've brought up this issue previously, just somehow it never caught 
> momentum. See, e.g.,
>     * https://sourceware.org/pipermail/libc-alpha/2022-November/143386.html
>     * https://sourceware.org/pipermail/libc-alpha/2023-January/144963.html
>     A more detailed discussion of different possible approaches in Gentoo can 
> be found on a wiki page 
>     maintained by Sam,
>     https://wiki.gentoo.org/wiki/Project:Toolchain/time64_migration
>     Discussions within Gentoo have led to the conclusion that a new CHOST 
> makes most sense, with
>     the old one staying at 32bit time_t for legacy binary support as 
> deprecated option.
> 
> [3] https://bpa.st/HV6BS
> 
> [4] https://sourceware.org/pipermail/libc-alpha/2022-November/143386.html
> 
> [5] Note that this entire issue / proposal only affects 32bit architectures 
> and distributions. 
>     For Gentoo this would be ix86, arm(32), hppa, mips(32), m68k, ppc(32).
>     riscv32 is special since from beginning it only has the 64bit time_t 
> interface.
> 
> -- 
> Andreas K. Hüttel
> dilfridge@gentoo.org
> Gentoo Linux developer 
> (council, comrel, toolchain, base-system, perl, libreoffice)
> https://wiki.gentoo.org/wiki/User:Dilfridge


Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/

signature.asc
Description: PGP signature