Re: Y2038 - best way forward in Debian?
* Ansgar:
> Arnd Bergmann writes:
>> On Mon, Feb 10, 2020 at 11:16 PM Florian Weimer <fw@deneb.enyo.de> wrote:
>>> There's going to be a _TIME_BITS selector, similar to
>>> _FILE_OFFSET_BITS.
>>>
>>> There was a proposal to have only one API before, but I think the
>>> agreement was that it wouldn't save much complexity.
>>
>> It should be easy to force the _TIME_BITS selection by patching the
>> glibc headers in Debian though if we want.
>>
>> The problem with setting _TIME_BITS=64 only using dpkg-buildflags
>> but leaving the libc default at 32 bits is that anything that users build
>> themselves or that ignores the buildflags ends up with a broken ABI
>> when linking against one of the many libraries that expose time_t
>> in their ABI.
>
> It breaks the other way too:
>
> If you have an old library with a time_t in some public ABI, but an
> application using it sets _TIME_BITS=64, the headers suddenly define a
> different ABI from the one implemented by the compiled library.
>
> If you rebuild the library with _TIME_BITS=64, it changes ABI too and
> breaks reverse dependencies (ignoring special handling like libc does
> with versioned symbols). So you cannot just change it by default.
>
> I don't understand how this can work unless time_t is *never* exposed by
> any library other than libc.
Correct. We have this problem with off_t today, which is used in some
header files. The problem is particularly thorny because like
off64_t, time64_t will never be a standard type, so some projects
don't want to use it in headers. And using time64_t would still be an
ABI break on i386.
Reply to: