Re: Proposed CHOST change for the 64bit time_t transition

[Andreas K. Huettel]

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-arm@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
dilfridge@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.