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.)