This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]