* Ansgar: > 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.
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.
