Re: Accelerating Y2038 glibc fixes

[Florian Weimer <fw@deneb.enyo.de>]

* Adhemerval Zanella:

> On 18/07/2019 16:13, Florian Weimer wrote:
>> * Adhemerval Zanella:
>> 
>>> So what about to not add a user-selected way to set the time_t size
>>> (as off_t) and just enable time64_t support and sets is as default for 
>>> build with a minimum kernel of v5.1 (if I recall correctly as being the 
>>> one that added time64 support)?
>> 
>> Does this mean that some developers see a glibc 2.31 with a 32-bit
>> time_t on i386, and others see a 64-bit time_t?
>> 
>>> It will move all time32 support as compat symbols for the required ABI, 
>>> without an option to select it through a build flag. Newer ports will
>>> just have the expected symbol names, no tinkering needed.
>> 
>> But if we build glibc with pre-5.1 kernel headers, you will get the
>> legacy interface?
>
> My idea is to setup based on --enable-kernel and add a new EI_ABIVERSION
> when time64 is used.  So, depending on how glibc is built, developers
> will indeed see a different time_t.
>
> Legacy builds won't build any time64 support, even with newer kernels.
> Build set with --enable-kernel will automatically set time_t as time64
> and redirect the required interfaces to the new symbols ones (similar
> to LFS, but transparently as _FILE_OFFSET_BITS=64 as being set as default).
>
> Newer 32-bit ports won't require anything like this as expected.
>
> I still think that in long term this initial bump transition is better
> than to the complexity from mixed support.

I've relayed this proposal to Debian and Fedora:

  <https://lists.debian.org/debian-devel/2019/07/msg00384.html>
  <https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/WMNZEREJU5JHB5DH6YDAHFLZJEU3IFEF/>

I suggest others do this for the distributions they care about.