Re: [Y2038] Trying Debian/armhf rebootstrap with time64
On Mon, Mar 16, 2020 at 3:47 PM Rich Felker wrote: > libtirpc is the replacement. I wasn't aware if uses libc-provided rpc > headers (presumably only if they exist, since folks are using it fine > on musl) but even if so I think the types will automatically update > when time_t changes. Of course that leaves the libtirpc ABI dependent > on which time_t is used. Ok, makes sense. I suppose it just provides a header with the same name then. Arnd ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] Trying Debian/armhf rebootstrap with time64
On Mon, Mar 16, 2020 at 03:28:43PM +0100, Arnd Bergmann wrote: > On Fri, Mar 13, 2020 at 9:22 PM Rich Felker wrote: > > > > On Wed, 11 Mar 2020 13:52:00 +01000, Arnd Bergmann wrote: > > > As discussed before, I tried using the rebootstrap tool [1] to see what > > > problems come up once the entire distro gets rebuilt. Based on Lukasz' > > > recommendation, I tried the 'y2038_edge' branch with his experimental > > > glibc patches [2], using commit c2de7ee9461 dated 2020-02-17. > > > > > > Here is a rough summary of what I tried, what worked, and what problems > > > I ran into: > > > > > > [...] > > > > > > * Actually building a time64 version of glibc turned out to be > > > harder, including some issues discussed on the libc mailing list[5]: > > > > > > - Always setting -D_TIME_BITS=64 in the global compiler flags for > > > the distro breaks both the native 64-bit (x86_64) build and the > > > 32-bit build, as glibc itself expects to be built without this. > > > > This seems like a small issue, but glibc should probably either remove > > it from CFLAGS in the build system or at least catch it at configure > > time and error out, so that it's not confusing when it breaks. > > Right, that would make sense. For the test suite though, I guess > it would actually need to run each test case that references > time_t both ways. Indeed. > > > - Removing the time32 symbols from the glibc shared object did not > > > work as they are still used (a lot) internally, and by the testsuite. > > > > That they're used internally sounds like a major problem; anywhere > > they're being used internally potentially has hidden Y2038 bugs. This > > is also why I'm concerned about glibc's approach of not building > > itself with _TIME_BITS=64, and just undefining it or doing something > > else in the wrapper files for the legacy time32 symbols. > > I thought this was the long-term plan. Working on the ABI first and > then changing the implementation may help speed up the timeline > before distro-level work can start, but OTOH removing all the 32-bit > codepaths from the implementation first makes it more likely to find > all relevant bits. In my experience it was easiest to do *with* the aid of the public header redirections applying internally to libc as well. I don't really understand how glibc is trying to make this easier by avoiding that. > > > - The nptl and sunrpc portions have numerous interfaces with > > > 'timeval' or 'timespec' arguments that each cause an ABI break. > > > > nptl is essential but I think sunrpc is pure legacy ABI and not > > intended to be linkable in the future. > > That would be helpful, but what does it mean for distro packages > that link against it today? > codesearch.debian.org e.g. finds nfs-utls, nis, libtirpc, ntirpc > and nfswatch including . Can these just use a > replacement that is built with 64-bit time_t then? libtirpc is the replacement. I wasn't aware if uses libc-provided rpc headers (presumably only if they exist, since folks are using it fine on musl) but even if so I think the types will automatically update when time_t changes. Of course that leaves the libtirpc ABI dependent on which time_t is used. Rich ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
Re: [Y2038] Trying Debian/armhf rebootstrap with time64
On Fri, Mar 13, 2020 at 9:22 PM Rich Felker wrote: > > On Wed, 11 Mar 2020 13:52:00 +01000, Arnd Bergmann wrote: > > As discussed before, I tried using the rebootstrap tool [1] to see what > > problems come up once the entire distro gets rebuilt. Based on Lukasz' > > recommendation, I tried the 'y2038_edge' branch with his experimental > > glibc patches [2], using commit c2de7ee9461 dated 2020-02-17. > > > > Here is a rough summary of what I tried, what worked, and what problems > > I ran into: > > > > [...] > > > > * Actually building a time64 version of glibc turned out to be > > harder, including some issues discussed on the libc mailing list[5]: > > > > - Always setting -D_TIME_BITS=64 in the global compiler flags for > > the distro breaks both the native 64-bit (x86_64) build and the > > 32-bit build, as glibc itself expects to be built without this. > > This seems like a small issue, but glibc should probably either remove > it from CFLAGS in the build system or at least catch it at configure > time and error out, so that it's not confusing when it breaks. Right, that would make sense. For the test suite though, I guess it would actually need to run each test case that references time_t both ways. > > - Removing the time32 symbols from the glibc shared object did not > > work as they are still used (a lot) internally, and by the testsuite. > > That they're used internally sounds like a major problem; anywhere > they're being used internally potentially has hidden Y2038 bugs. This > is also why I'm concerned about glibc's approach of not building > itself with _TIME_BITS=64, and just undefining it or doing something > else in the wrapper files for the legacy time32 symbols. I thought this was the long-term plan. Working on the ABI first and then changing the implementation may help speed up the timeline before distro-level work can start, but OTOH removing all the 32-bit codepaths from the implementation first makes it more likely to find all relevant bits. > > - The nptl and sunrpc portions have numerous interfaces with > > 'timeval' or 'timespec' arguments that each cause an ABI break. > > nptl is essential but I think sunrpc is pure legacy ABI and not > intended to be linkable in the future. That would be helpful, but what does it mean for distro packages that link against it today? codesearch.debian.org e.g. finds nfs-utls, nis, libtirpc, ntirpc and nfswatch including . Can these just use a replacement that is built with 64-bit time_t then? Arnd ___ Y2038 mailing list Y2038@lists.linaro.org https://lists.linaro.org/mailman/listinfo/y2038
