This is the mail archive of the
mailing list for the glibc project.
Re: Fourth draft of the Y2038 design document
- From: Arnd Bergmann <arnd at arndb dot de>
- To: libc-alpha at sourceware dot org
- Cc: Joseph Myers <joseph at codesourcery dot com>, Albert ARIBAUD <albert dot aribaud at 3adev dot fr>, Y2038 <y2038 at lists dot linaro dot org>
- Date: Thu, 23 Jun 2016 17:35:57 +0200
- Subject: Re: Fourth draft of the Y2038 design document
- Authentication-results: sourceware.org; auth=none
- References: <20160622005838 dot 60a95c44 dot albert dot aribaud at 3adev dot fr> <4582546 dot 7lC4NyOprV at wuerfel> <alpine dot DEB dot 2 dot 20 dot 1606231425220 dot 21240 at digraph dot polyomino dot org dot uk>
On Thursday, June 23, 2016 2:32:50 PM CEST Joseph Myers wrote:
> On Thu, 23 Jun 2016, Arnd Bergmann wrote:
> > > I'd be a lot more comfortable with requiring new kernel headers to build
> > > and use glibc than with requiring a new kernel at runtime for
> > > _TIME_BITS=64 to work. New kernel headers are one of the easiest things
> > > to use when building glibc, since we have the --with-headers option. (In
> > > fact right now the headers requirement (3.2) is newer than the runtime
> > > requirement (2.6.32) on x86_64 / x86.)
> > Just for my understanding: do you mean requiring new headers specifically
> > for building with _TIME_BITS=64 as I said, or would you change the minimum
> > kernel header version for building glibc in general when we merge 64-bit
> > time_t support?
> My view would be changing the minimum for building glibc in general,
> rather than trying to make installed libc headers check the kernel headers
> version and give errors conditional on _TIME_BITS. (I think we can trust
> distribution maintainers to set appropriate dependencies so that in this
> case glibc doesn't get used with old headers if built with new headers.)
Ok, thanks for clarifying.
> > Fair enough. And this would also mean that we don't allow 32-bit
> > time_t on future architectures ports that never had an upstream Linux
> > kernel without 64-bit time_t interfaces, right?
> I'd expect such future architectures to be in the case where _TIME_BITS=64
> does nothing, much like existing 64-bit architecture ports and NaCl.
> > On a related note, is there still a plan to allow building a glibc
> > with 32-bit time_t disabled? I asked for that to be included in the
> > past, but I don't see it in the Albert's document now, so I'm guessing
> > that it was intentionally removed again.
> A given glibc port has a given set of existing ABIs, which can't be
> removed without changing the SONAME. That doesn't rule out making some of
> the old ABIs into compat symbols and disallowing building new binaries
> with _TIME_BITS=32, but that would be several years down the line if done
> at all.
Ok, got it.
> (I expect we'll want to change the default for _FILE_OFFSET_BITS well
> before changing the _TIME_BITS default. For _FILE_OFFSET_BITS, patches
> were posted a while back, and eventually evidence that
> _FILE_OFFSET_BITS=64 is the API most widely used for building libraries
> where it matters on GNU/Linux distributions; those patches need
I think the two flags are somewhat different from a user perspective:
_FILE_OFFSET_BITS=64 is generally a good idea and is required for some
applications, while others are fine without it. In contrast, _TIME_BITS=64
has zero benefit for most users of 32-bit machines, but for those people
that need it, it is essential that /all/ user space is built with that
I would also guess that it's harder distros to do a gradual migration
for time_t than it is for off_t because there are more libraries that
expose interfaces with time_t and those libraries do not all use
symbol versioning but would get a silent ABI break from rebuilding
I expect that most distros will not turn _TIME_BITS=64 at all because
it's easier to just stop supporting 32-bit binaries at some point
in the next 20 years, while the ones that plan to keep supporting them
will not do a gradual migration but instead force a rebuild of all
binaries at the same time.
For the second use case, a changed SONAME would make sense too, but
I understand this is not something you'd introduce lightly, and
it's clear from your explanation that you wouldn't add this for
the first version.
Is there a policy about what justifies such an ABI break? I.e. is it
possible to add a build-time configuration flag later that disables
32-bit time_t support for an existing architecture while setting
a different SONAME, assuming there is sufficient user interest for
this feature? I see a couple of different options that change SONAME
on https://sourceware.org/glibc/wiki/ABIList, but those are all
for fundamental incompatibilities, not for voluntary ABI breaks.