> 2) the transition to default time64 breaks legacy 32bit binaries in
>    unpredictable ways

Since the size of time_t is changing, a transition to a default 64bit interface
changes the public ABI of all libraries that integrate this type in any way.
Which means, if an application is linked to such a library, and the library is
later recompiled, undefined behaviour ensues.

This was discussed already in the previous thread on this list [1], with reactions
ranging from "need new triplet" via "need new libdir" to "meh".
The latter is a bit surprising given how much emphasis glibc usually places on 
backwards compatibility.

While we could certainly go ahead and invent a solution in Gentoo here, this
makes no sense at all for one distribution alone. This is an upstream problem
and should be solved here... pretty please? opinions?

[1] https://sourceware.org/pipermail/libc-alpha/2022-November/143386.html



Am Donnerstag, 26. Januar 2023, 00:57:31 CET schrieb Andreas K. Huettel:
> Dear all, 
> 
> now that the 2.37 release and with that another half year of delay is near, 
> I'd like to remind everyone that we still need to find some decent solution
> for the remaining problems associated with time64 and LFS as discussed
> earlier [1].
> 
> As far as I can see at the moment there are two things that need a solution.
> 
> 1) qemu usermode emulation is broken when emulating a 32bit arch from a 64bit
>    arch, bug 23960
>  
> 2) the transition to default time64 breaks legacy 32bit binaries in
>    unpredictable ways
> 
> I'm going to reply with two separate e-mails for these issues, and would be
> very happy for your opinions and contributions on the respective threads.
> 
> Cheers,
> Andreas 
> (Gentoo toolchain team)
> 
> [1] https://sourceware.org/pipermail/libc-alpha/2022-November/143386.html
> 
> 


-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)