This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Fourth draft of the Y2038 design document
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Arnd Bergmann <arnd at arndb dot de>
- Cc: <libc-alpha at sourceware dot org>, Albert ARIBAUD <albert dot aribaud at 3adev dot fr>, Y2038 <y2038 at lists dot linaro dot org>
- Date: Thu, 23 Jun 2016 14:32:50 +0000
- 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> <6204150 dot Ja8izhmCjv at wuerfel> <alpine dot DEB dot 2 dot 20 dot 1606222012420 dot 22324 at digraph dot polyomino dot org dot uk> <4582546 dot 7lC4NyOprV at wuerfel>
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.)
> 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.
(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
resurrecting.)
--
Joseph S. Myers
joseph@codesourcery.com