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-gnut6
Hi Wookey,
> > 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].
>
> > * In an ideal world this change would be synchronized across distributions.
> >
>
> FWIW, yocto/openembedded have also done the same and offered a distro
> setting to the users
> to select 32bit time_t if they wished to but defaulted to 64bit time_t.
In case of Openembedded, which (as far as I understand) mostly offers
complete system images for download or build, I might ha
Hi Todd,
> Versioned symbols in glibc should mean that old binaries will still run (even
> if they
> misbehave when they look at the system time), just like with most previous
> ABI changes
> to libc over the years.
That is irrelevant here. glibc takes care of its own interface and is not a
> One possible improvement would be to append "t32" if you want 32-bit
> time_t, instead of appending "t64" for 64-bit time_t.
I hope you aren't earnestly proposing this worst of both worlds idea
(let's change CHOST for any system with no ABI change).
> I felt the same way about the 64-bit off
Am Donnerstag, 5. September 2024, 20:20:32 CEST schrieb Paul Eggert:
> On 2024-09-05 10:03, Andreas K. Huettel wrote:
> > at least time64 implies largefile, so that will get sorted as side
> > effect.
>
> Right, but this means the "t" in "t64" is somewhat misleading, as it's
> not just about time
Am Dienstag, 10. September 2024, 01:08:36 CEST schrieb Arsen Arsenović:
> Jacob Bachmeyer writes:
>
> >> At that point, we should bump SONAME of libc and simply remove 32-bit
> >> time support. This would probably be okay generally.
> >
> > This is probably the best solution to this problem at h
