On Fri, Sep 6, 2024 at 10:21 AM Andreas K. Huettel <dilfridge@xxxxxxxxxx> wrote: > > 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. There are other threads on this mailing list mentioning mailman problems when cross-posting to multiple lists. Probably not a moderator intervention. > 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-- > _______________________________________________ > 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 -- _______________________________________________ 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
