Proposed CHOST change for the 64bit time_t transition

Proposed CHOST change for the 64bit time_t transition

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 3380 bytes --]

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@gentoo.org
Gentoo Linux developer 
(council, comrel, toolchain, base-system, perl, libreoffice)
https://wiki.gentoo.org/wiki/User:Dilfridge

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Proposed CHOST change for the 64bit time_t transition

[Oskari Pirhonen]

[-- Attachment #1: Type: text/plain, Size: 1512 bytes --]

On Wed, Sep 04, 2024 at 17:48:04 +0200, Andreas K. Huettel wrote:
> 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.
> 

...

> [3] https://bpa.st/HV6BS

FYI, this paste expires in 1 week. Here's the contents:

diff '--color=auto' -ruN ncurses-6.4.orig/aclocal.m4 ncurses-6.4/aclocal.m4
--- ncurses-6.4.orig/aclocal.m4	2024-08-29 20:47:34.978057133 +0000
+++ ncurses-6.4/aclocal.m4	2024-08-29 20:48:57.809473044 +0000
@@ -10139,7 +10139,7 @@
 	cf_xopen_source="-D_SGI_SOURCE"
 	cf_XOPEN_SOURCE=
 	;;
-(linux*gnu|linux*gnuabi64|linux*gnuabin32|linux*gnueabi|linux*gnueabihf|linux*gnux32|uclinux*|gnu*|mint*|k*bsd*-gnu|cygwin|msys|mingw*|linux*uclibc)
+(linux*gnu*|uclinux*|gnu*|mint*|k*bsd*-gnu|cygwin|msys|mingw*|linux*uclibc)
 	CF_GNU_SOURCE($cf_XOPEN_SOURCE)
 	;;
 (minix*)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Proposed CHOST change for the 64bit time_t transition

[Wookey]

[-- Attachment #1: Type: text/plain, Size: 4582 bytes --]

On 2024-09-04 17:48 +0200, Andreas K. Huettel wrote:
> 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].

> * In an ideal world this change would be synchronized across distributions. Opinions? [5]

Debian considered this issue over the last 18 months/2 years, and
found very little enthusiasm for making new triplets. Every distro
that is using 64-bit time (on 32-bit arches) just enabled the flags
and changed the ABI without setting a new arch/triplet (or they have
dropped 32-bit stuff entirely so sidestepped the issue).

Given this, and because users would like to just be upgraded to 64-bit
time, not have to install a new architecture, Debian and Ubuntu
decided not to try and push a new triplet and do a library-name ABI
update within the architecture(s). That went ahead between March and
June this year and is now pretty-much done, modulo a few outstanding
bugs
(https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-arm@lists.debian.org;tag=time-t).

Debian's thinking and status is summarised here: https://wiki.debian.org/ReleaseGoals/64bit-time

So it's interesting that in fact Gentoo _does_ want to do this, but it
seems to me that this is now a done deal, and 'everyone' has already
switched within the existing triplets, even Debian, which is the
hardest place to do this because it involved 1100 library transitions,
with another 3500-odd rebuilds.

> [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

Yes. We did a big ABI analysis to find out how many libraries were
affected (including LFS which glibc ties into this transition) and it
was about 700. (there were quite a few more where the automated ABI
tools failed and it was easier to do a transition than work out why,
so we ended up transitioning 1093 source packages
(https://people.canonical.com/~vorlon/armhf-time_t/source-packages).

So yes it's an ABI change, but we don't always change the triplet for
this, sometimes we just move the baseline along. This happened in the
last for glibc 5->6 and libstdc++ v4 to v5 and the long-double
redefinition in s390,alpha, sparc, powerpc. In fact, considering the
whole-distro collective ABI, this happens every time there is an ABI
change in a library. The arch/triplet remains the same, but the new
release has a different ABI in some number of libraries and
dependencies.

So it's always a choice whether the triplet should change or it is
just treated as an update, and usually the latter is chosen. This was
a borderline case that could have gone either way, but people decided
to do it as a transition, not a new triplet.

Are you sure gentoo will gain enough value from going it alone here
and defining a new triplet? Because every other distro will have (has
already got in fact) the t64 ABI with the old triplet.


> [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@gentoo.org
> Gentoo Linux developer 
> (council, comrel, toolchain, base-system, perl, libreoffice)
> https://wiki.gentoo.org/wiki/User:Dilfridge


Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Proposed CHOST change for the 64bit time_t transition

[Khem Raj]

On Wed, Sep 4, 2024 at 7:07 PM Wookey <wookey@wookware.org> wrote:
>
> On 2024-09-04 17:48 +0200, Andreas K. Huettel wrote:
> > 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].
>
> > * In an ideal world this change would be synchronized across distributions. Opinions? [5]
>
> Debian considered this issue over the last 18 months/2 years, and
> found very little enthusiasm for making new triplets. Every distro
> that is using 64-bit time (on 32-bit arches) just enabled the flags
> and changed the ABI without setting a new arch/triplet (or they have
> dropped 32-bit stuff entirely so sidestepped the issue).
>
> Given this, and because users would like to just be upgraded to 64-bit
> time, not have to install a new architecture, Debian and Ubuntu
> decided not to try and push a new triplet and do a library-name ABI
> update within the architecture(s). That went ahead between March and
> June this year and is now pretty-much done, modulo a few outstanding
> bugs
> (https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-arm@lists.debian.org;tag=time-t).
>
> Debian's thinking and status is summarised here: https://wiki.debian.org/ReleaseGoals/64bit-time
>

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.

> So it's interesting that in fact Gentoo _does_ want to do this, but it
> seems to me that this is now a done deal, and 'everyone' has already
> switched within the existing triplets, even Debian, which is the
> hardest place to do this because it involved 1100 library transitions,
> with another 3500-odd rebuilds.
>
> > [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
>
> Yes. We did a big ABI analysis to find out how many libraries were
> affected (including LFS which glibc ties into this transition) and it
> was about 700. (there were quite a few more where the automated ABI
> tools failed and it was easier to do a transition than work out why,
> so we ended up transitioning 1093 source packages
> (https://people.canonical.com/~vorlon/armhf-time_t/source-packages).
>
> So yes it's an ABI change, but we don't always change the triplet for
> this, sometimes we just move the baseline along. This happened in the
> last for glibc 5->6 and libstdc++ v4 to v5 and the long-double
> redefinition in s390,alpha, sparc, powerpc. In fact, considering the
> whole-distro collective ABI, this happens every time there is an ABI
> change in a library. The arch/triplet remains the same, but the new
> release has a different ABI in some number of libraries and
> dependencies.
>
> So it's always a choice whether the triplet should change or it is
> just treated as an update, and usually the latter is chosen. This was
> a borderline case that could have gone either way, but people decided
> to do it as a transition, not a new triplet.
>
> Are you sure gentoo will gain enough value from going it alone here
> and defining a new triplet? Because every other distro will have (has
> already got in fact) the t64 ABI with the old triplet.
>
>
> > [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@gentoo.org
> > Gentoo Linux developer
> > (council, comrel, toolchain, base-system, perl, libreoffice)
> > https://wiki.gentoo.org/wiki/User:Dilfridge
>
>
> Wookey
> --
> Principal hats:  Debian, Wookware, ARM
> http://wookware.org/

Re: Proposed CHOST change for the 64bit time_t transition

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 709 bytes --]

> 
> 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 have done that
similarly at the start - this is a different situation.

That said, nothing would keep you from trivially still switching the CHOST
in case of enabled 64bit time_t, to be able to keep the two variants apart.

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer 
(council, comrel, toolchain, base-system, perl, libreoffice)
https://wiki.gentoo.org/wiki/User:Dilfridge

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Proposed CHOST change for the 64bit time_t transition

[Paul Eggert]

One possible improvement would be to append "t32" if you want 32-bit 
time_t, instead of appending "t64" for 64-bit time_t. That way, people 
wouldn't be stuck with appending that confusing "t64" for the 
foreseeable future, and only specialists concerned with 32-bit time_t 
would need to know about the issue.

Personally, I hope backward-compatibility concerns don't require this 
sort of thing. I'd rather just switch, as Debian has.

I felt the same way about the 64-bit off_t back in the 1990s. It was 
obvious to me even at the time that we would have been significantly 
better off making off_t 64-bit, while keeping 32-bit off_t in the ABI 
for backward compatibility; this is what NetBSD did with time_t in 2012. 
Although I realize others felt differently, I never fully understood 
their concerns.

And here I am, three decades later, still having to make changes[1] to 
Autoconf's AC_SYS_LARGEFILE macro to continue to support that 
30-year-old off_t mistake, and now with 64-bit time_t interacting with 
64-off_t in non-orthogonal ways.

[1]: 
https://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=b71143738516017f0e0d347a4025301c06c40254

Re: Proposed CHOST change for the 64bit time_t transition

[Todd Vierling]

> One possible improvement would be to append "t32" if you want 32-bit
> time_t, instead of appending "t64" for 64-bit time_t.

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. Generally the triplet has never changed except to flag that something is being intentionally built for an *older* API/ABI. For instance, autoconf had for some time a separate triplet to identify a.out/libc5/glibc1 when ELF/libc6/glibc2 had become the new standard, flagging the deprecated rather than current revision.

Like previous base libc ABI changes, yes, it means rebuilding all downstream libraries and applications to make use of the new API/ABI. What matters is whether it's "easy" to pick up a mix of shared objects built for different ABIs which are representing a data type differently. The thing being asked here is fundamentally a search for a technical solution to this risk, but changing a triplet alone doesn't address that risk at all.

Some technical options to address the actual question include:

1. Total flag day. No versioned symbols, no compatibility.

2. Partial flag day. Provide only the bare minimum of compatibility libraries, and intentionally change the versions (sonames) of libc-downstream libraries so that new binaries won't pick the old libraries. Applications that dlopen("libfoo.so") will break, but... please don't dlopen() an unversioned .so filename kthx because that already risks ABI breakage.

3. Keep new libraries partitioned; no more installing directly into /usr/lib{,64} depending on your distro, rather everything must now go in a new place, and the dynamic linker needs to know which paths to use and which to ignore. This would require new executables being tagged in some form at link time.

4. Same as (3), but the dynamic linker needs to know where *compatibility* libraries are installed for older binaries, and choose that path in preference instead of the standard one. Still requires new executables being tagged to tell the difference.

-- 
-- Todd Vierling, Oracle Linux Sustaining and Security <todd.vierling@oracle.com>

Re: Proposed CHOST change for the 64bit time_t transition

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 2686 bytes --]

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 problem.

The types exported by glibc, as used in *other* libraries' interfaces, are the problem.

> Generally the triplet has never changed except to flag that something is being 
> intentionally built for an *older* API/ABI. For instance, autoconf had for some time 
> a separate triplet to identify a.out/libc5/glibc1 when ELF/libc6/glibc2 had become the 
> new standard, flagging the deprecated rather than current revision.

That's incorrect, else we wouldn't have -gnueabi (on arm) or -gnuabin32 (on mips).

> What matters is whether it's "easy" to pick up a mix of shared objects built for different 
> ABIs which are representing a data type differently. The thing being asked here is 
> fundamentally a search for a technical solution to this risk, but changing a triplet 
> alone doesn't address that risk at all.

Maybe not alone, but it minimizes the risk of accidental confusion, and makes 100%
clear which ABI is present.

> 
> Some technical options to address the actual question include:
> 

Most of this is actually irrelevant to the specific question I'm asking, because...

> 1. Total flag day. No versioned symbols, no compatibility.
> 
> 2. Partial flag day. Provide only the bare minimum of compatibility libraries, and 
> intentionally change the versions (sonames) of libc-downstream libraries so that new 
> binaries won't pick the old libraries. Applications that dlopen("libfoo.so") will break, 
> but... please don't dlopen() an unversioned .so filename kthx because that already risks 
> ABI breakage.

... how this is done exactly during the transition is something each distribution can
easily organize on their own. Doesn't mean we can't talk about it, but it's right now and
in this context not important.

> 3. Keep new libraries partitioned; no more installing directly into /usr/lib{,64} 
> depending on your distro, rather everything must now go in a new place, and the dynamic 
> linker needs to know which paths to use and which to ignore. This would require new e
> xecutables being tagged in some form at link time.

Yes. I was already joking about 'libt64'. (That was a JOKE, please please please dont
take it serious.)


-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer 
(council, comrel, toolchain, base-system, perl, libreoffice)
https://wiki.gentoo.org/wiki/User:Dilfridge

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Proposed CHOST change for the 64bit time_t transition

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 1173 bytes --]

> 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_t back in the 1990s. It was 
> obvious to me even at the time that we would have been significantly 
> better off making off_t 64-bit, while keeping 32-bit off_t in the ABI 
> for backward compatibility; this is what NetBSD did with time_t in 2012. 
> Although I realize others felt differently, I never fully understood 
> their concerns.
> 
> And here I am, three decades later, still having to make changes[1] to 
> Autoconf's AC_SYS_LARGEFILE macro to continue to support that 
> 30-year-old off_t mistake, and now with 64-bit time_t interacting with 
> 64-off_t in non-orthogonal ways.

Well, at least time64 implies largefile, so that will get sorted as side
effect.


-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer 
(council, comrel, toolchain, base-system, perl, libreoffice)
https://wiki.gentoo.org/wiki/User:Dilfridge

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Proposed CHOST change for the 64bit time_t transition

[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: it also affects off_t, ino_t, etc., effects that 
are in some cases more important than the time_t effects. It may well be 
a good idea to use a different suffix, to remind non-experts about these 
other issues. How about "wsi" for "wider system integers"? E.g., 
i686-pc-linux-gnuwsi.

Is the plan to call these APIs XXXt64 or XXXwsi forever, even after the 
year 2038? For example, will i686-pc-linux-gnu be withdrawn in a few years?

How would you deal with the problem that i686-pc-linux-gnu would mean 
one thing in Gentoo and something else in Debian? (This was what I was 
hinting at when I suggested adding a suffix for 32-bit time_t instead of 
for 64-bit.)

Re: Proposed CHOST change for the 64bit time_t transition

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 1999 bytes --]

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: it also affects off_t, ino_t, etc., effects that 
> are in some cases more important than the time_t effects. It may well be 
> a good idea to use a different suffix, to remind non-experts about these 
> other issues. How about "wsi" for "wider system integers"? E.g., 
> i686-pc-linux-gnuwsi.

... or -gnutf64 (for time and files)?

No objections against such variations in principle, just we should keep it
as simple and straightforward as possible then.

> Is the plan to call these APIs XXXt64 or XXXwsi forever, even after the 
> year 2038? For example, will i686-pc-linux-gnu be withdrawn in a few years?

I'd expect that all the 32bit linux variants will slowly sink into obscurity.
(By 2038, we're probably more concerned with the 64bit to 128bit transition.)

Apart from that, I see no real need for further change later on.

> How would you deal with the problem that i686-pc-linux-gnu would mean 
> one thing in Gentoo and something else in Debian? (This was what I was 
> hinting at when I suggested adding a suffix for 32-bit time_t instead of 
> for 64-bit.)

Well, of course I would hope that I can still convince them that tacking on t64
makes sense. After all, it's easy for them now. ;) Otherwise...

Following the logic of riscv versus riscv64 versus riscv32, one could come up
with a "global" definition of
* t64 suffix = 64bit time and lfs
* no suffix = can be either, your fault for not being informative, distro default
* t32 suffix = 32bit time (and ...?)


-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer 
(council, comrel, toolchain, base-system, perl, libreoffice)
https://wiki.gentoo.org/wiki/User:Dilfridge

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Proposed CHOST change for the 64bit time_t transition

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 4584 bytes --]

Paul Eggert <eggert@cs.ucla.edu> writes:

> One possible improvement would be to append "t32" if you want 32-bit time_t,
> instead of appending "t64" for 64-bit time_t. That way, people wouldn't be
> stuck with appending that confusing "t64" for the foreseeable future, and only
> specialists concerned with 32-bit time_t would need to know about the issue.

But that'd change semantics in non-obvious ways.  The intention behind
this suggestion is to have a mechanism to communicate to packages and
the toolchain alike that "yes, this system is Y2038-proof".  There is
currently no mechanism to do that.  There isn't even a mechanism to
guess based on your dependencies whether you should also enable LFS and
T64 (and there can't be a general one - you'd need to detect what
libraries are doing what if they have time_t or other system integers on
ABI boundaries, which is not generally possible).  Not that the latter
would suffice - even if we changed all packages we can to use such a
mechanism, there would be plenty of packages that don't (think of all
the hand-rolled makefiles..).

An alternative that I pondered was to teach the linker about some notion
of "compatibility strings" that it would compare and reject if
different, plus teaching the compiler how to emit those, plus teaching
glibc to tell the compiler to emit those..  We could have key-value
pairs in some section.  For each key K, we could have the linker check
that, for each (shared or otherwise) object either does not contain K or
contains K with the same value as all the other ones, and produce an
error otherwise.  On the resulting object, the KV pairs would be the
union of all KV pairs of all constituent objects.

... but this is for i?86, a CPU family I haven't used in ~15 years (and
I suspect many also have not..), and there are other things eating my
time.  And it'd still require a world rebuild.

> Personally, I hope backward-compatibility concerns don't require this sort of
> thing. I'd rather just switch, as Debian has.

The "status quo" of some packages enabling it of their own volition, and
some not, leads to various subtle breakages (example:
https://bugs.gentoo.org/828001).  I think switching like that would not
be much different.

I do not know what approach Debian took, but if it is one of altering
the toolchain, then this is a sure way to introduce subtle divergences
between distros (this is why I've suggested we CC the GCC and binutils
MLs); if it is one of teaching debhelper (is that the right tool?  not
sure) about it, then this will break user-compiled packages (so,
./configure && make && make install, or moral equivalent).  If it is to
alter libc, then, can we do libc.so.7?  ;)

The only actually solid approach I see today is to /somehow/ communicate
to the system to not use 32-bit time, ever (and consequently, to enable
LFS).  I think that the "least effort" path to do that is through the
tuple.

There's precedent for this also, AFAIK, in the 32-bit ARM world
(gnueabi/gnueabihf, whatever that means).

config.guess would need to be altered a little bit.  My preference is
for [[ $os = *-*-gnu*t64* ]] informing glibc to completely ignore
_FILE_OFFSET_BITS, _LARGEFILE_SOURCE, _LARGEFILE64_SOURCE, and
_TIME_BITS and just presume 64 for all of those system integers.  This
means that config.guess could undef those (in case a toolchain sets
those) and include some libc file, then check for sizeof (time_t), or
just have glibc define something if on a gnut64 target.

> I felt the same way about the 64-bit off_t back in the 1990s. It was obvious to
> me even at the time that we would have been significantly better off making
> off_t 64-bit, while keeping 32-bit off_t in the ABI for backward compatibility;
> this is what NetBSD did with time_t in 2012. Although I realize others felt
> differently, I never fully understood their concerns.

That is history now I fear; I also wish that time_t was made
64-bit a long ago ;)

> And here I am, three decades later, still having to make changes[1] to
> Autoconf's AC_SYS_LARGEFILE macro to continue to support that 30-year-old off_t3
> mistake, and now with 64-bit time_t interacting with 64-off_t in non-orthogonal
> ways.

Indeed, and the "best" part is that, whatever you do in autoconf, unless
a program exists in isolation only interfacing with libc, it will break
some consumer (or will be broken by some dependency) because there's no
mechanism to signal the time_t size across ABI boundaries.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: Proposed CHOST change for the 64bit time_t transition

[Bruno Haible]

Arsen Arsenović wrote:
> An alternative that I pondered was to teach the linker about some notion
> of "compatibility strings" that it would compare and reject if
> different, plus teaching the compiler how to emit those, plus teaching
> glibc to tell the compiler to emit those..  We could have key-value
> pairs in some section.  For each key K, we could have the linker check
> that, for each (shared or otherwise) object either does not contain K or
> contains K with the same value as all the other ones, and produce an
> error otherwise.  On the resulting object, the KV pairs would be the
> union of all KV pairs of all constituent objects.

This sounds much like the arm eabi attributes: If a .s file does not
start with
        .eabi_attribute 20, 1
        .eabi_attribute 21, 1
        .eabi_attribute 23, 3
        .eabi_attribute 24, 1
        .eabi_attribute 25, 1
        .eabi_attribute 26, 2
        .eabi_attribute 30, 2
        .eabi_attribute 34, 0
        .eabi_attribute 18, 4
the resulting .o file cannot be linked with other .o files on the system.

Is it a hassle even for packages that don't use time_t of off_t (such as
GNU libffcall or libffi).

Yes, it would be useful to have a way to have the linker warn if a binary
that depends on 32-bit time_t and a binary that depends on 64-bit time_t
get linked together. But PLEASE implement this in a way that is a no-op
when time_t is not used by either of the two binaries.

Bruno

Re: Proposed CHOST change for the 64bit time_t transition

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 1902 bytes --]

Bruno Haible <bruno@clisp.org> writes:

> Arsen Arsenović wrote:
>> An alternative that I pondered was to teach the linker about some notion
>> of "compatibility strings" that it would compare and reject if
>> different, plus teaching the compiler how to emit those, plus teaching
>> glibc to tell the compiler to emit those..  We could have key-value
>> pairs in some section.  For each key K, we could have the linker check
>> that, for each (shared or otherwise) object either does not contain K or
>> contains K with the same value as all the other ones, and produce an
>> error otherwise.  On the resulting object, the KV pairs would be the
>> union of all KV pairs of all constituent objects.
>
> This sounds much like the arm eabi attributes: If a .s file does not
> start with
>         .eabi_attribute 20, 1
>         .eabi_attribute 21, 1
>         .eabi_attribute 23, 3
>         .eabi_attribute 24, 1
>         .eabi_attribute 25, 1
>         .eabi_attribute 26, 2
>         .eabi_attribute 30, 2
>         .eabi_attribute 34, 0
>         .eabi_attribute 18, 4
> the resulting .o file cannot be linked with other .o files on the system.
>
> Is it a hassle even for packages that don't use time_t of off_t (such as
> GNU libffcall or libffi).
>
> Yes, it would be useful to have a way to have the linker warn if a binary
> that depends on 32-bit time_t and a binary that depends on 64-bit time_t
> get linked together. But PLEASE implement this in a way that is a no-op
> when time_t is not used by either of the two binaries.

I mentioned that a missing pair should not preclude linking.  This is
because what I imagined is somehow attaching this tag to the typedef for
time_t, or such, so if the typedef is not used, no such tag is emitted.

I'm not sure how feasible that is, I, of course, don't have a full
implementation.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: Proposed CHOST change for the 64bit time_t transition

[Bruno Haible]

Paul Eggert wrote:
> I'd rather just switch, as Debian has.

I'd go one step further, and not only
  make the ABI transition without changing the canonical triplet,
but also
  make gcc and clang define -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64
  among their predefines.

Rationale:

  * We want that a user of a distro with the new ABI can build
    packages in the usual way:
      - ./configure; make; make install (when using Autoconf), or
      - make; make install  (when there is just a Makefile).
    This *requires* that gcc and clang get patched, as indicated
    above.
    (Only changing Debian-specific files or variables won't do it.)

  * Once this has been done, is there a need for a triplet change?
    Not in the toolchain, and not in the packages either.
    Needs that have been mentioned in [1][2]:

      - Users would like to know in which ABI they / their distro lives.
        This can be done through a property in /etc/os-release.

      - "risks incompatibility with other distributions" [2]
        What is the problem? Do we expect users to build binaries
        on 32-bit distro X and try to run them on 32-bit distro Y?
        Or do we expect binary package distributors (like Mozilla,
        videolan.org) to do so?
        It was my impression that this approach is doomed anyway,
        because so many shared libraries have different major version
        in distro X than in distro Y.
        And that such binary package distributors use flatpak, AppImage, etc.
        precisely to get out of this dilemma.

      - Building gcc and glibc might need some particular options.
        Such options can be documented without requiring a new triplet.

References:
[1] https://wiki.debian.org/ReleaseGoals/64bit-time
[2] https://wiki.gentoo.org/wiki/Project:Toolchain/time64_migration

Re: Proposed CHOST change for the 64bit time_t transition

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 2932 bytes --]

Bruno Haible <bruno@clisp.org> writes:

> Paul Eggert wrote:
>> I'd rather just switch, as Debian has.
>
> I'd go one step further, and not only
>   make the ABI transition without changing the canonical triplet,
> but also
>   make gcc and clang define -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64
>   among their predefines.

At that point, we should bump SONAME of libc and simply remove 32-bit
time support.  This would probably be okay generally.  Just doing the
predefine doesn't really fix anything - all the problems of not being
able to detect whether t64 support exists still persist, with no
mechanism to prevent mixing.

But, in the case we don't do a bump, why not update the tuple?  This'd
allow easy communication of whether we have 32 bit time to all
components of the system, and, in lieu of a better detection mechanism,
it'd allow anyone at a glance to look at a hosts tuple and see whether
it is compatible with something based on the tuple it was built on.

AFAIK the only reason not to do that is cosmetic - and it is ugly, but
this is for a dead platform, so I'm not too worried.

> Rationale:
>
>   * We want that a user of a distro with the new ABI can build
>     packages in the usual way:
>       - ./configure; make; make install (when using Autoconf), or
>       - make; make install  (when there is just a Makefile).
>     This *requires* that gcc and clang get patched, as indicated
>     above.
>     (Only changing Debian-specific files or variables won't do it.)
>
>   * Once this has been done, is there a need for a triplet change?
>     Not in the toolchain, and not in the packages either.
>     Needs that have been mentioned in [1][2]:
>
>       - Users would like to know in which ABI they / their distro lives.
>         This can be done through a property in /etc/os-release.
>
>       - "risks incompatibility with other distributions" [2]
>         What is the problem? Do we expect users to build binaries
>         on 32-bit distro X and try to run them on 32-bit distro Y?
>         Or do we expect binary package distributors (like Mozilla,
>         videolan.org) to do so?
>         It was my impression that this approach is doomed anyway,
>         because so many shared libraries have different major version
>         in distro X than in distro Y.

It is, many do it anyway, and what's worse, many users misguidedly
prefer it to better approaches (like the ones you mentioned).

>         And that such binary package distributors use flatpak, AppImage, etc.
>         precisely to get out of this dilemma.
>
>       - Building gcc and glibc might need some particular options.
>         Such options can be documented without requiring a new triplet.
>
> References:
> [1] https://wiki.debian.org/ReleaseGoals/64bit-time
> [2] https://wiki.gentoo.org/wiki/Project:Toolchain/time64_migration

-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: Proposed CHOST change for the 64bit time_t transition

[Jacob Bachmeyer]

Arsen Arsenović wrote:
> Bruno Haible <bruno@clisp.org> writes:
>   
>> Paul Eggert wrote:
>>     
>>> I'd rather just switch, as Debian has.
>>>       
>> I'd go one step further, and not only
>>   make the ABI transition without changing the canonical triplet,
>> but also
>>   make gcc and clang define -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64
>>   among their predefines.
>>     
>
> 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 hand, especially 
since the old ABI has a definite expiration date about 14 years from 
now.  Bump the libc SONAME major and hope that we can get rid of the 
last dependencies on the old SONAME before the deadline.  We will have 
14 years to do it, if that arch is even still used then.

> [...]
> But, in the case we don't do a bump, why not update the tuple?  This'd
> allow easy communication of whether we have 32 bit time to all
> components of the system, and, in lieu of a better detection mechanism,
> it'd allow anyone at a glance to look at a hosts tuple and see whether
> it is compatible with something based on the tuple it was built on.
>   

This is closely related to the idea I floated a year ago of redefining 
configuration tuples as lists of tags (with a canonical order) 
progressively narrowing a broad architecture.  Start with CPU 
architecture and work "narrower" from there.  In that system, adding 
"-t32" and "-t64" to indicate time_t width would be the simple 
solution.  In context then, it was to handle different libc choices on 
Windows.


-- Jacob

Re: Proposed CHOST change for the 64bit time_t transition

[Arsen Arsenović]

[-- Attachment #1: Type: text/plain, Size: 1680 bytes --]

Jacob Bachmeyer <jcb62281@gmail.com> 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 hand, especially since
> the old ABI has a definite expiration date about 14 years from now.  Bump the
> libc SONAME major and hope that we can get rid of the last dependencies on the
> old SONAME before the deadline.  We will have 14 years to do it, if that arch
> is even still used then.

Indeed.  I believe the current thinking is that the existing software
for the old ABI could benefit from libc updates, hence not breaking it,
but.. it practically is somewhat broken already (hence the troubles that
lead to this thread).

>> [...]
>> But, in the case we don't do a bump, why not update the tuple?  This'd
>> allow easy communication of whether we have 32 bit time to all
>> components of the system, and, in lieu of a better detection mechanism,
>> it'd allow anyone at a glance to look at a hosts tuple and see whether
>> it is compatible with something based on the tuple it was built on.
>>   
>
> This is closely related to the idea I floated a year ago of redefining
> configuration tuples as lists of tags (with a canonical order) progressively
> narrowing a broad architecture.  Start with CPU architecture and work
> "narrower" from there.  In that system, adding "-t32" and "-t64" to indicate
> time_t width would be the simple solution.  In context then, it was to handle
> different libc choices on Windows.

Yes, that's about what I imagined as the effect of the suffix.
-- 
Arsen Arsenović

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 381 bytes --]

Re: Proposed CHOST change for the 64bit time_t transition

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]

Am Dienstag, 10. September 2024, 01:08:36 CEST schrieb Arsen Arsenović:
> Jacob Bachmeyer <jcb62281@gmail.com> 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 hand, especially since
> > the old ABI has a definite expiration date about 14 years from now.  Bump the
> > libc SONAME major and hope that we can get rid of the last dependencies on the
> > old SONAME before the deadline.  We will have 14 years to do it, if that arch
> > is even still used then.
> 
> Indeed.  I believe the current thinking is that the existing software
> for the old ABI could benefit from libc updates, hence not breaking it,
> but.. it practically is somewhat broken already (hence the troubles that
> lead to this thread).
> 

This is all nice and good, but I would actually like to focus on realistic
targets (ie., ones which could be achieved significantly before 2038... :o)

That's also the beauty of only appending t64 to the last quadruplet field, 
most software is not impacted by it and just accepts it.

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer 
(council, comrel, toolchain, base-system, perl, libreoffice)
https://wiki.gentoo.org/wiki/User:Dilfridge

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Proposed CHOST change for the 64bit time_t transition

[Todd Vierling]

> This is all nice and good, but I would actually like to focus on realistic
> targets (ie., ones which could be achieved significantly before 2038... :o)

Right — there are distro releases shipping over the next few years which will still be deployed in production in 2038, so the clock is actually running out fast for some of us :)

-- 
-- Todd Vierling, Oracle Linux Sustaining and Security <todd.vierling@oracle.com>

Re: Proposed CHOST change for the 64bit time_t transition

[Florian Weimer]

* Arsen Arsenović via Gcc:

> Bruno Haible <bruno@clisp.org> writes:
>
>> Paul Eggert wrote:
>>> I'd rather just switch, as Debian has.
>>
>> I'd go one step further, and not only
>>   make the ABI transition without changing the canonical triplet,
>> but also
>>   make gcc and clang define -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64
>>   among their predefines.
>
> At that point, we should bump SONAME of libc and simply remove 32-bit
> time support.  This would probably be okay generally.  Just doing the
> predefine doesn't really fix anything - all the problems of not being
> able to detect whether t64 support exists still persist, with no
> mechanism to prevent mixing.

Defaulting to 64-bit time_t would also make dlsym etc. work again.  For
post-GLIBC_2.1 targets (where valid binaries are expected to use symbol
versioning) it's not absolutely required to do a soname bump, just
changing the symbol version baseline should be enough (set DEFAULT to
e.g. GLIBC_2.40 in shlib-versions).  Old binaries will use
__libc_start_main@GLIBC_2.4 or __libc_start_main@GLIBC_2.34, and fail to
load.  This could be a more source-compatible change becaue I suspect
not everyone uses LIBC_SO in <gnu/lib-names.h> to get the soname for
libc.so.

I do not have a strong opinion whether this should be done for most
32-bit targets.  Except for i386, where I think we should aim to
preserve compatibility with legacy binaries for many years to come.

All these changes have implications for LSB complinace, as people keep
reminding us:

  LoongArch glibc does not provide libutil shared object, against LSB 5.0 
  <https://sourceware.org/bugzilla/show_bug.cgi?id=31136>

But as I explained on the ticket, the way LSB is constructed, it's
surprisingly architecture-specific even in its generic parts, and 32-bit
Arm with its GLIBC_2.4 baseline won't have the required GLIBC_2.3.4
symbols (such as __chk_fail@GLIBC_2.3.4) anyway.

Thanks,
Florian

Re: Proposed CHOST change for the 64bit time_t transition

[Khem Raj]

On Thu, Sep 5, 2024 at 6:51 AM Andreas K. Huettel <dilfridge@gentoo.org> wrote:
>
> >
> > 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 have done that
> similarly at the start - this is a different situation.

OpenEmbedded and Gentoo are alike in some respects, they are source
based distributions with
some pre-builts, I thought it must be easier for gentoo compared to
binary distros.

>
> That said, nothing would keep you from trivially still switching the CHOST
> in case of enabled 64bit time_t, to be able to keep the two variants apart.
>

it does have impact on OE when packages ( configure ) start depending
upon these new tuples
for enabled/disabling stuff.

> --
> Andreas K. Hüttel
> dilfridge@gentoo.org
> Gentoo Linux developer
> (council, comrel, toolchain, base-system, perl, libreoffice)
> https://wiki.gentoo.org/wiki/User:Dilfridge

Re: Proposed CHOST change for the 64bit time_t transition

[Andreas K. Huettel]

[-- Attachment #1: Type: text/plain, Size: 4664 bytes --]

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. Opinions? [5]
> 
> Debian considered this issue over the last 18 months/2 years, and
> found very little enthusiasm for making new triplets. 

I guess you mean "little enthusiasm within Debian".

I mean, I still remember your slides and attempts at clarification at FOSDEM, I was 
there and definitely tried to get a conversation going. And we've also been sounding 
out cooperation otherwise.

> Every distro that is using 64-bit time (on 32-bit arches) just enabled the flags
> and changed the ABI without setting a new arch/triplet 

Could you maybe specify "every distro" a bit further? I'd guess Debian and Ubuntu, 
plus Yocto/OpenEmbedded (which is in my opinion a special case, see separate
reply)?

> time, not have to install a new architecture, Debian and Ubuntu
> decided not to try and push a new triplet and do a library-name ABI
> update within the architecture(s). That went ahead between March and
> June this year and is now pretty-much done, modulo a few outstanding
> bugs
> (https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian-arm@lists.debian.org;tag=time-t).

Which does not really change the long term problem we're trying to address.
I mean, one of the nice things about open source systems is that you can
keep legacy systems working for a long time without needless binary compatibility
breaks. The glibc developers are the real specialists for that.

TL;DR: Thanks for trying, we want to do better.

> seems to me that this is now a done deal, and 'everyone' has already
> switched within the existing triplets, even Debian, which is the

Again, please define "everyone".

> > [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
> 
> Yes. We did a big ABI analysis to find out how many libraries were
> affected (including LFS which glibc ties into this transition) and it
> was about 700. (there were quite a few more where the automated ABI
> tools failed and it was easier to do a transition than work out why,
> so we ended up transitioning 1093 source packages
> (https://people.canonical.com/~vorlon/armhf-time_t/source-packages).

Very nice work. It shows the overall problem is actually larger than I assumed.

Doing the transition without giving a d*** about historical compatibility
would be fairly easy for Gentoo, after all, we are a rolling release, 
source-based distribution, and rebuilds of packages are normal for our users.
That said, we tend to take the job serious and minimize the breakage.

> So yes it's an ABI change, but we don't always change the triplet for
> this, sometimes we just move the baseline along. This happened in the
> last for glibc 5->6 and libstdc++ v4 to v5 and the long-double
> redefinition in s390,alpha, sparc, powerpc. In fact, considering the
> whole-distro collective ABI, this happens every time there is an ABI
> change in a library. The arch/triplet remains the same, but the new
> release has a different ABI in some number of libraries and
> dependencies.

Most of the examples that you are listing here have a built-in mechanism
for coping with the upgrade.
As an example, a library changes soversion, and there is no reason not
to keep a library with the old version around if you need it still.
We have, e.g., in Gentoo a security-masked library-only package for
openssl 1.0 and 1.1 should anyone still need it, or even libstdc++ 3.

About s390, alpha, sparc, powerpc - yes, even our criteria might be a bit
looser there, however, that's mostly because the ecosystem is much smaller. 
There should be by far not so many legacy binaries floating around in 
comparison to x86.

> This was
> a borderline case that could have gone either way, but people decided
> to do it as a transition, not a new triplet.

I guess you mean "Debian decided". We certainly haven't heard from you.

Cheers,
Andreas

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer 
(council, comrel, toolchain, base-system, perl, libreoffice)
https://wiki.gentoo.org/wiki/User:Dilfridge

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Proposed CHOST change for the 64bit time_t transition

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2694 bytes --]

Hello,

On Thu, 2024-09-05 at 03:06 +0100, Wookey wrote:
> So it's interesting that in fact Gentoo _does_ want to do this, but it
> seems to me that this is now a done deal, and 'everyone' has already
> switched within the existing triplets, even Debian, which is the
> hardest place to do this because it involved 1100 library transitions,
> with another 3500-odd rebuilds.

I disagree with this claim, and I really feel like in this whole thread
people are underestimating the gravity of this situation.

In the case of Gentoo, being a source distribution implies that
the vast majority of users are building everything from source.  While
binary packages are supported to some degree, this is not something we
can rely on.  As such, we need to assume that the transition will
involve rebuilding everything from source.

This in turn implies rebuilding whole production systems, bottom up. 
This means that there will be significant periods of time during which
production systems will be running with ABI incompatibilities between
programs and their dependent libraries, and these periods will be much
longer than if binary packages were used.  In other words, production
systems will be quasi-broken for extended period of time.

What's even more dangerous is that any particular rebuild can actually
fail -- and then the user may suddenly be left with a quasi-broken
system, pending urgent recovery.  I mean, just imagine that one of your
dependent libraries failed to rebuild, and you end up having a 32-bit
time_t program with some of its dependencies using 32-bit time_t,
and others 64-bit time_t already -- and you suddenly have to figure out
how to make the problematic package build again, or revert everything
back.

Now, I'm not an expert on ABI but I do believe that the potential for
breakage is pretty serious.  After all, we are talking about doubling
the type size.  So we're talking about function parameters being
shifted, struct offset mismatches, stack corruption, heap corruption...

I think it does make sense to clearly indicate that this is a serious
change of ABI.  Furthermore, I personally would even go as far as to
change libdir, as to ensure that we can rebuild everything without
immediately breaking production systems in place.

On top of that, we need to account for the fact that users may have some
executables that they've compiled and linked to the system libraries
themselves, and these also may start suddenly misbehaving.  So perhaps
the right thing is to ensure that you can't even run an executable
unless all its linked libraries use the same time_t variant.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 512 bytes --]