Proposed CHOST change for the 64bit time_t transition

--nextPart1974747.tdWV9SEqCh
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; protected-headers="v1"
From: "Andreas K. Huettel" <[email protected]>
Subject: Proposed CHOST change for the 64bit time_t transition
Date: Wed, 04 Sep 2024 17:48:04 +0200
Message-ID: <4996568.GXAFRqVoOG@noumea>
Organization: Gentoo Linux
MIME-Version: 1.0

Dear all,=20

in Gentoo Linux we want to change our CHOST triplets for 32-bit glibc syste=
ms that use 64-bit time_t, since
this is technically an ABI change which breaks binary compatibility [1].

We are thinking of adding a "t64" suffix to the ABI field, resulting in for=
 example i686-pc-linux-gnut64,
armv7a-unknown-linux-gnueabihft64, ... [2]

* So far my research indicates that in the GNU toolchain (gcc, glibc, binut=
ils) anything behind -gnu is=20
  ignored (as ABI version, which this effectively is too). Is this correct =
or do you foresee problems here?
  I've had a small chroot rebuild itself (the Gentoo @system set) with i686=
=2Dpc-linux-gnut64 and only had to
  add a minor patch to ncurses [3]; everything else worked fine.

* clang at the moment expects one of a list of known suffixes (e.g. *-gnu, =
*-gnueabi, *-gnueabihf).=20
  Could this be fixed to be similarly permissive?

* I could imagine glibc defaulting to the 64bit interface or hard-enabling =
it if t64 is present=20
  in the ABI field. That would certainly help to enforce binary consistency.
  We would need then either an automated mechanism based on CHOST or a glib=
c configure option to
  hard-enable 64bit time_t support [4].
  Not hard-required by Gentoo, we can just force the defines into everythin=
g, but would-be-neat.

* In an ideal world this change would be synchronized across distributions.=
 Opinions? [5]

Deliberately pushing this e-mail out now so maybe it can be discussed at th=
e cauldron. I won't be there,=20
but Sam James and Arsen Arsenovic will be.
If this proposal fails, the alternative for us is to add a _t64 suffix to t=
he vendor field, resulting in
e.g. i686-pc_t64-linux-gnu. The vendor field is pretty much ignored everywh=
ere, so going alone is safe.
Still, that's then a purely Gentoo ugly hack...

Cheers, Andreas


[1] The ABI of glibc does technically NOT change, however, the type definit=
ion 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=20
    https://bugs.gentoo.org/828001

[2] We've brought up this issue previously, just somehow it never caught mo=
mentum. 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 c=
an 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 m=
akes most sense, with
    the old one staying at 32bit time_t for legacy binary support as deprec=
ated 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.=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 in=
terface.

=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
--nextPart1974747.tdWV9SEqCh
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+rT3CsWIV7VQSoFAmbYgTQACgkQ3CsWIV7V
QSrJFBAAgGR0hF63Zmg7T6InkY719dI/mn8mroykQDXl/pFc+5zNaZfyiunzAo+7
Tsgr9tu3XOTytbORIQAc+4J/BWHkvGH4/pIkegjmIkdJcmSlqbort3KKxucKP0Bk
V0L4vBfySEtCO4ew5Cp3jFuEdvMVpTAWxlS4Q4+qXWe3M0Yq2ogjd28ci69NakxE
GHnx3P7KWNhK4yXAxx7V+fxVOoCJL12EWyVn+12IjhE7QsifZNpT5kTWOPfXjxqH
zZgx7OUgwlXRTyH2wpVjB2nIzoFHUkn9MTcfQMXacF5e1WxQUEsZ6zHqggtC0AhR
ABXU2kCVDNS5WapQPecBGEveNS6NyyV8EmUh7ZxtPGiZG2zCi00NHPG1e6umcv71
miabzmW/3UwOGJxvMOs1EuUyoZwfaAaGeRwERf5P8yULe4QlgpQuImsW0/Z75Nfj
ENU/Ue0EuFe/NV5qDVDLS5H++OaBQyEMl5tzY7kw1qJIPzdQ43rouCO0IqziaJAw
qVWMXUgF/1JKeLt/xSHfdiBgQr0hJLMps4EVLHBQhEXFGdpf4G/zJCLLkGtWbYAW
E8U02OI+2Jtg3KEuMllFQZ1DL38otJ+6shwwSojSm4afrAQUIxJvYYzeFPnljg0B
9M3/B/5uCWL3tgl7GqK/o2NAMO6wSt/z7VMN38w6fvUEWt5wjvw=
=ceDP
-----END PGP SIGNATURE-----

--nextPart1974747.tdWV9SEqCh--