Hi Wookey, > > 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.
I guess you mean "little enthusiasm within Debian". I mean, I still remember your slides and attempts at clarification at FOSDEM, I was there and definitely tried to get a conversation going. And we've also been sounding out cooperation otherwise. > 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 Could you maybe specify "every distro" a bit further? I'd guess Debian and Ubuntu, plus Yocto/OpenEmbedded (which is in my opinion a special case, see separate reply)? > 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). Which does not really change the long term problem we're trying to address. I mean, one of the nice things about open source systems is that you can keep legacy systems working for a long time without needless binary compatibility breaks. The glibc developers are the real specialists for that. TL;DR: Thanks for trying, we want to do better. > seems to me that this is now a done deal, and 'everyone' has already > switched within the existing triplets, even Debian, which is the Again, please define "everyone". > > [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). Very nice work. It shows the overall problem is actually larger than I assumed. Doing the transition without giving a d*** about historical compatibility would be fairly easy for Gentoo, after all, we are a rolling release, source-based distribution, and rebuilds of packages are normal for our users. That said, we tend to take the job serious and minimize the breakage. > 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. Most of the examples that you are listing here have a built-in mechanism for coping with the upgrade. As an example, a library changes soversion, and there is no reason not to keep a library with the old version around if you need it still. We have, e.g., in Gentoo a security-masked library-only package for openssl 1.0 and 1.1 should anyone still need it, or even libstdc++ 3. About s390, alpha, sparc, powerpc - yes, even our criteria might be a bit looser there, however, that's mostly because the ecosystem is much smaller. There should be by far not so many legacy binaries floating around in comparison to x86. > This was > a borderline case that could have gone either way, but people decided > to do it as a transition, not a new triplet. I guess you mean "Debian decided". We certainly haven't heard from you. Cheers, Andreas -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, comrel, toolchain, base-system, perl, libreoffice) https://wiki.gentoo.org/wiki/User:Dilfridge
signature.asc
Description: This is a digitally signed message part.
