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