[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] year2038: support glibc 2.34 _TIME_BITS=64

From: Paul Eggert
Subject: Re: [PATCH] year2038: support glibc 2.34 _TIME_BITS=64
Date: Fri, 16 Jul 2021 22:39:51 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0

On 7/8/21 12:36 AM, Florian Weimer wrote:

Doesn't this argue against _TIME_BITS=64 in general? It seems to be
saying that one should just recompile for 64-bit, and never use
I think it does, but apparently 32-bit Arm is an outlier, related to
DRAM sizes.  I'm still not convinced that glibc needs to support that,
but the community wasn't opposed to it.

It's a tricky situation then, since 32-bit ARM is evidently intended to last past 2038, which means Coreutils etc. built now should be built to survive past 2038, hence the Gnulib change. And once that snowball starts rolling down the hill it's going to keep rolling until it reaches the bottom.

Two separate i386 ports seem to require the least human
resources to maintain.
That's a reasonable approach and if people want to do that they can,
even with the latest Gnulib and the next version of Glibc.

However, people who want to run old binaries will surely stick to the
32-bit-time_t i386 port, which means they won't use the 64-bit-time_t
i386 port. So it's not clear to me that they will cotton to this approach.
Sorry, I don't understand.  Which approach?

I meant the approach of having two i386 ports (or two ARM ports, for that matter). People who want to run old binaries will insist on the 32-bit time_t port, which means the 64-bit time_t port won't be used those people. In other words I think we're agreeing.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]