Re: Trying Debian/armhf rebootstrap with time64
- To: Steve McIntyre <steve@einval.com>
- 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>, 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, 23 Mar 2020 20:44:05 +0100
- Message-id: <[🔎] CAK8P3a0rvKU_ie2r0ai1fVm9kmgs8Fa9d21fo_xU50nU4FNc1w@mail.gmail.com>
- In-reply-to: <[🔎] 20200323182044.GX5169@tack.einval.com>
- References: <[🔎] CAK8P3a0EtmgDRbDzBhOOZk_kyWmCm1aqvSxwUeY0R7tbCSxaKg@mail.gmail.com> <[🔎] 20200323182044.GX5169@tack.einval.com>
On Mon, Mar 23, 2020 at 7:21 PM Steve McIntyre <steve@einval.com> wrote:
> On Wed, Mar 11, 2020 at 01:52:00PM +0100, Arnd Bergmann wrote:
> >* Adding a time64 armhf as a separate (incompatible) target in glibc
> > that defines __TIMESIZE==64 and a 64-bit __time_t would avoid
> > most of the remaining ABI issues and put armhf-time64 in the same
> > category as riscv32 and arc, but this idea was so far rejected by the
> > glibc maintainers. Depending on how hard this turns out to be,
> > it could be used to get to the point of self-hosting though, and
> > help find time64 related bugs in the rest of the distro.
>
> OK. I'm thinking it's probably not worth it?
This depends on the timeline of Lukasz' work. My feeling is that there is still
quite a bit to be done before it's worth trying the Debian bootstrap again.
If you or someone else wants to continue where I stopped with the Debian
rebuilding without waiting for the complete glibc port, adding a new armhf
target to glibc on top of the current glibc-y2038 tree is probably a quicker
way to get something that builds and boots. I don't know how much work
exactly there would be for this approach, but my feeling is that it's not that
much after looking at the kind of problems I ran into, and at the state of
the riscv32 port that uses the same approach.
Arnd
Reply to: