On Fri, Mar 13, 2020 at 9:22 PM Rich Felker dalias@libc.org 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 <rpc/*.h>. Can these just use a replacement that is built with 64-bit time_t then?
Arnd