Re: Proposed CHOST change for the 64bit time_t transition

--nextPart2281663.Mh6RI2rZIc
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; protected-headers="v1"
From: "Andreas K. Huettel" <[email protected]>
To: Wookey <[email protected]>
Subject: Re: Proposed CHOST change for the 64bit time_t transition
Date: Thu, 05 Sep 2024 15:49:07 +0200
Message-ID: <4449180.ejJDZkT8p0@noumea>
Organization: Gentoo Linux
In-Reply-To: <[email protected]>
MIME-Version: 1.0

Hi Wookey,

> > in Gentoo Linux we want to change our CHOST triplets for 32-bit glibc s=
ystems that use=20
> > 64-bit time_t, since this is technically an ABI change which breaks bin=
ary compatibility [1].
>=20
> > * In an ideal world this change would be synchronized across distributi=
ons. Opinions? [5]
>=20
> Debian considered this issue over the last 18 months/2 years, and
> found very little enthusiasm for making new triplets.=20

I guess you mean "little enthusiasm within Debian".

I mean, I still remember your slides and attempts at clarification at FOSDE=
M, I was=20
there and definitely tried to get a conversation going. And we've also been=
 sounding=20
out cooperation otherwise.

> Every distro that is using 64-bit time (on 32-bit arches) just enabled th=
e flags
> and changed the ABI without setting a new arch/triplet=20

Could you maybe specify "every distro" a bit further? I'd guess Debian and =
Ubuntu,=20
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/[email protected]=
ebian.org;tag=3Dtime-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 compati=
bility
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 def=
inition of, e.g., time_t does.
> >     And as soon as any other library includes that in its public interf=
aces and data structures, that library
> >     changes its ABI.
> >     An example for an affected library (found real-world during testing=
) is gnutls, see=20
> >     https://bugs.gentoo.org/828001
>=20
> 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 assu=
med.

Doing the transition without giving a d*** about historical compatibility
would be fairly easy for Gentoo, after all, we are a rolling release,=20
source-based distribution, and rebuilds of packages are normal for our user=
s.
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.=
=20
There should be by far not so many legacy binaries floating around in=20
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

=2D-=20
Andreas K. H=FCttel
[email protected]
Gentoo Linux developer=20
(council, comrel, toolchain, base-system, perl, libreoffice)
https://wiki.gentoo.org/wiki/User:Dilfridge
--nextPart2281663.Mh6RI2rZIc
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEE/Rnm0xsZLuTcY+rT3CsWIV7VQSoFAmbZttMACgkQ3CsWIV7V
QSr61g/9FGIh/JGY7KdScp1fXptFnE8x4iTtb8d03AQCZVoC2FGMahbkicLNYris
6Xqe+LiguRNiTxYuLPp6AWKNErbtiru/Y+ib1dULIZ4XpdAoacbsvaIKq3+unAlu
01Nm4ISmBJuYPlBfCufkZtRXR5mhYEdRXxVLKlkUHpz2oPazYkxguAQUPAHR7AJb
p48c/30cuGijry7d1oPHMQrKPlsAV2x28MX82uG357C5PO2CYfeoVJRHibsRTOqB
92CL3WIM+t753x298ZxACGpxMyh+s1rrAVJD+5YmDb58P7MwTYbsdBQt2rHxkrop
X1LX5ZqWmNxxvNhebKSgjf81naIs9EeAPHjv/XsYJfIJA+VcU7duVjmra8E5d/JH
BytTgLB1XajwTnRwL3abnJH9uJkpw/F9QGEAl2+P7VIFLf8w6/2BjkK5Bg+qwqe6
pfEXL+JUZKLC53rpFmye2XWM20HD+07+FzWsQWx2iaQBu+DHdreWHqVHfBaNopKv
Z5Sv04XrE6Tfs0y7pPi9S2TNIzjTbrBWKFka/6yPBoGKfe8Ux/DVK4U/O2AWFmoY
6HHr5RFWzjdbfAyeNsYIdYnyMELYex3rnMJx+4qvWQusZyS/7uwbJjRokKz3SlUm
KbrLrHNiiPv3DvySKg6l1xHXkJejDkor0euK/ik2Gkx5wYr6IQ4=
=QNRW
-----END PGP SIGNATURE-----

--nextPart2281663.Mh6RI2rZIc--