This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Accelerating Y2038 glibc fixes
* 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.