On Wednesday, June 22, 2016 8:19:36 PM CEST Joseph Myers wrote: > On Wed, 22 Jun 2016, Arnd Bergmann wrote: > > > We can avoid most of the problems if building with _TIME_BITS=64 > > has no effect unless both glibc and the kernel headers are new > > enough to provide the definitions for 64-bit time_t. That way > > we can at least ensure that calling an ioctl command or setsockopt > > with an incompatible ABI will result in an error code rather than > > wrong data. > > 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? > (_TIME_BITS=64 should of course be an OS-independent API, supported for > all glibc configurations. Obviously exactly what Hurd does is up to the > Hurd maintainers, as probably is fixing Hurd to keep it working with > _TIME_BITS=64, but _TIME_BITS=64 should clearly enable 64-bit time_t for > it even if some underlying Y2038-safety is missing. NaCl already has > 64-bit time_t so _TIME_BITS=64 would have no effect there.) 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? 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. Arnd _______________________________________________ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038