Arnd Bergmann writes: > On Mon, Feb 10, 2020 at 11:16 PM Florian Weimer <f...@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