On Wed, Sep 4, 2024 at 7:07 PM Wookey <woo...@wookware.org> wrote: > > 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 >
FWIW, yocto/openembedded have also done the same and offered a distro setting to the users to select 32bit time_t if they wished to but defaulted to 64bit time_t. > 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/
