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