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

[Paul Eggert <eggert@cs.ucla.edu>]

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
>> _TIME_BITS=64.
> 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.