Re: Proposed CHOST change for the 64bit time_t transition

--7v2SkOxZkOkgWk1E
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2024-09-04 17:48 +0200, Andreas K. Huettel wrote:
> Dear all,=20
>=20
> in Gentoo Linux we want to change our CHOST triplets for 32-bit glibc sys=
tems 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 distribution=
s. 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/[email protected]=
ian.org;tag=3Dtime-t).

Debian's thinking and status is summarised here: https://wiki.debian.org/Re=
leaseGoals/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 defin=
ition of, e.g., time_t does.
>     And as soon as any other library includes that in its public interfac=
es 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

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.ht=
ml
>     * 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=20
>     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 depr=
ecated option.
>=20
> [3] https://bpa.st/HV6BS
>=20
> [4] https://sourceware.org/pipermail/libc-alpha/2022-November/143386.html
>=20
> [5] Note that this entire issue / proposal only affects 32bit architectur=
es and distributions.=20
>     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.
>=20
> --=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


Wookey
--=20
Principal hats:  Debian, Wookware, ARM
http://wookware.org/

--7v2SkOxZkOkgWk1E
Content-Type: application/pgp-signature; name="signature.asc"

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

iQIzBAABCgAdFiEER4nvI8Pe/wVWh5yq+4YyUahvnkcFAmbZEhMACgkQ+4YyUahv
nkeEWA//aFQSabQJcwsKBo7cdm3uB3ruyXkPEFtW0ky85hzYlE1HhDxm9gghasCN
OrtC20KnXZlPk8f0LSXRVCYenfG8w7mJMI0sfVYaBP6mk+0BlQm8nxe9Gtn99s44
RLwaUa7FspWcwFbOxujDCJgedpxqMNU6lXoamQePlqeXGd4Pjkz8W+0+SlYStj/9
OYfThuPBOCUV3ODSSRX27nd33D+FxJa6AVJTlRNqlMM8szUJ5aIcf61gjf+je2p7
uQAe06ApBtx5MNKYbKSWTKvrvbNFwUkSXL4RqKpPb4fdMz4fWWKqqHtayzzT9XKV
ZE4hq8q33fpM2cIJWEnAkfuu/F2R+byYMe7GwZS38VO4QX5t4T3vyyAzqlUp2twW
nsAKe1r/5WqAUjTl5/A1pOTB80CK9KM6JB/n4z+58+aDjT4TrzymQCN5zkWzW0yf
EWHUOx2MVdn1t2pn5odmnbaBu7vqLysCrwtE2bqpFe07vj9po7DIPeWvbo39yy+N
rq/qSt/FUQ3hLWGCAmYHAenOwhtDfXz8AZfwUIvs88rrf+Z1NfeabpeygPg/zyH9
EXWemxV6qw/Sfk/+/kJJ1It804V6Qzh7rYIvGoDBcygMntVMYwYnXRDERtuoj0hZ
9WujFpjQ6/yvpDUyl28LqVZ5drumgRuOj1jmfXhunS9gHTU9BNI=
=0JEa
-----END PGP SIGNATURE-----

--7v2SkOxZkOkgWk1E--