* Arsen Arsenović via Gcc:
> Bruno Haible 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 -
> 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 actuall
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
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 hand, especially since
> the old ABI has a definite expiration date about 14 years fr
Arsen Arsenović wrote:
Bruno Haible 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
Bruno Haible 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 predefi
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 beca
Bruno Haible 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 em
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
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
Paul Eggert 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
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
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 importa
> 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
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
On Thu, Sep 5, 2024 at 6:51 AM Andreas K. Huettel 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)
> 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 chan
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 abou
>
> 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 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.
> >
On Wed, Sep 4, 2024 at 7:07 PM Wookey 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 com
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 b
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 addin
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
24 matches
Mail list logo
