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
dilfridge@xxxxxxxxxx
Gentoo Linux developer
(council, comrel, toolchain, base-system, perl, libreoffice)
https://wiki.gentoo.org/wiki/User:DilfridgeAttachment:
signature.asc
Description: This is a digitally signed message part.
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
