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 _______________________________________________ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038