Seems like the fedora list moderators decided to not let the follow-ups pass to the fedora-dev list, so please if you're interested follow the discussion on one of the other involved mailing lists. I'm fairly sure this is also relevant here. E.g., see for the thread https://sourceware.org/pipermail/libc-alpha/2024-September/159610.html Cheers, Andreas Am Mittwoch, 4. September 2024, 17:48:04 CEST schrieb Andreas K. Huettel: > 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:Dilfridge
Attachment:
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
