On Fri, Mar 13, 2020 at 9:22 PM Rich Felker <dal...@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
