Re: Trying Debian/armhf rebootstrap with time64
- To: Rich Felker <dalias@libc.org>
- Cc: y2038 Mailman List <y2038@lists.linaro.org>, GNU C Library <libc-alpha@sourceware.org>, debian-arm@lists.debian.org, tcwg@linaro.org, Helmut Grohne <helmutg@debian.org>, Wookey <wookey@wookware.org>, Adhemerval Zanella <adhemerval.zanella@linaro.org>, Steve McIntyre <steve@einval.com>, Lukasz Majewski <lukma@denx.de>, Jan Kiszka <jan.kiszka@web.de>, Riku Voipio <riku.voipio@iki.fi>
- Subject: Re: Trying Debian/armhf rebootstrap with time64
- From: Arnd Bergmann <arnd@arndb.de>
- Date: Mon, 16 Mar 2020 15:28:43 +0100
- Message-id: <[🔎] CAK8P3a0eDr5d1s9mqfs7HXXeCMAT7=dxftbM91ny0f6fAd3Zjg@mail.gmail.com>
- In-reply-to: <20200313202234.GA3980@brightrain.aerifal.cx>
- References: <[🔎] CAK8P3a0EtmgDRbDzBhOOZk_kyWmCm1aqvSxwUeY0R7tbCSxaKg@mail.gmail.com> <20200313202234.GA3980@brightrain.aerifal.cx>
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
Reply to: