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.
Ok.
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 resurrecting.)
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 option.
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 with _TIME_BITS=64.
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.
Arnd