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-...@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 > dilfri...@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
