Re: Y2038 - best way forward in Debian?

[Ansgar <ansgar@43-1.org>]

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.

Ansgar