[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Y2038 - best way forward in Debian?



On Mon, Feb 10, 2020 at 11:16 PM Florian Weimer <fw@deneb.enyo.de> wrote:
>
> * Ben Hutchings:
>
> > On Sun, 2020-02-09 at 11:57 +0100, Florian Weimer wrote:
> >> * Ben Hutchings:
> >>
> >> > If I recall correctly, glibc *will* provide both entry points, so there
> >> > is no ABI break.  But the size of time_t (etc.) exposed through libc-
> >> > dev is fixed at glibc build time.
> >>
> >> Is this a Debian-specific decision?
> >
> > I though that was the *upstream* decision, but perhaps that's still not
> > decided after all?
>
> 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.

         Arnd


Reply to: