Re: Y2038 - best way forward in Debian?
On Tue, Feb 11, 2020 at 9:10 PM Florian Weimer <fw@deneb.enyo.de> wrote:
> * 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.
I think Steve explained this already in the initial email: in approach A,
rebuilding any library that exposes a modified time_t implies an incompatible
library update and updating anything that depends on it to be built with
the time64 interface as well, which quickly gets out of hand when you do this
recursively.
With approach B, there is no attempt at binary compatibility, instead
a new armhf_time64 port would use the same package names and
versions as the existing armhf port, but have an incompatible ABI
for anything exposing time_t based interfaces. Changing the target
triplet then allows a multiarch installation to coexist with armhf, the
same way that you can have armel and armhf coexisting today, with
an incompatible ABI.
> 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.
AFAIU time64_t is not even going to be exposed in the glibc headers
in the first place, you just pick which ABI you get when compiling an
application and hope it matches the other libraries.
Arnd
Reply to: