Dear all, 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].
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, binutils)
anything behind -gnu is
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-pc-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).
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
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 glibc
configure option to
hard-enable 64bit time_t support [4].
Not hard-required by Gentoo, we can just force the defines into everything,
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 the
cauldron. I won't be there,
but Sam James and Arsen Arsenovic will be.
If this proposal fails, the alternative for us is to add a _t64 suffix to the
vendor field, resulting in
e.g. i686-pc_t64-linux-gnu. The vendor field is pretty much ignored everywhere,
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 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
[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.html
* 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
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 deprecated
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.
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.
--
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.
