Arnd Bergmann wrote on Wed, Sep 28, 2022 at 08:21:00AM +0200:
> (It was Steve who did the recap of the work that I had done)
(woops, sorry. Thank you both!)
> > tl;dr: glibc 2.34 added a -D_TIME_BITS=64 toggle, but afaiu we need to
> > rebuild (virtually) everything to use it as that breaks the ABI for
> > anything using time_t
> >
> >
> > As far as I'm aware, there haven't been any new public discussion since
> > that 2020 thread -- has there been any new attempt I missed?
>
> I am not aware of anyone trying to do another bootstrap after me.
>
> From what I can tell, the main thing that has changed is that there
> is even less developer time that we can spend on armhf. With every
> year that passes, more workloads are moving from 32-bit userspace
> native 64 bit, so the number of people that is willing to help
> out is going down, though that does not necessarily make it less
> important to those that do care about 32 bit.
>
> Another thing that has changed is that /other/ 32-bit distros are
> getting dropped, notably Fedora 37 dropped 32-bit Armv7 support,
> and Arch Linux dropped support for any platform without NEON
> support. OpenWRT on the other hand just had their first release
> that is using 64-bit time_t on all musl-based targets, though
> not yet on i386+glibc.
Yes, we also released our first aarch64 board earlier this year (end of
2021 actually), but we still plan on using armv7 for a while longer so
we cannot just ignore that... Unfortunately as a very small company I'm
afraid the amount of help I can give is rather limited at this point.
> > My naive opinion is that having a flag day and dealing with fallouts
> > might ultimately be the fastest way forward, but as there won't be any
> > safety check to detect incompatibility I don't think anyone will be
> > looking forward to the weird errors that will ensure for e.g. locally
> > compiled programs and whatsnot.
> >
> > So that might be the first thing to think about again?
> > (... and I wish I had any idea there, but nothing practical to
> > suggest...)
>
> I would agree that the idea of doing a soft migration that
> correctly tracks library dependencies and allows a safe dist-upgrade
> across the rebuild is pretty much dead because of the burden this
> would put on package maintainers, so it will have to be fresh
> time64 bootstrap.
>
> Last time, the discussion got stuck because that means introducing
> a new target name for dpkg, which then requires a new target triplet
> to allow a multiarch installation. This in turn requires additional
> work for porting packages that need to know about the new target
> triplet.
Ugh, this is going to be a massive headache...
Other distributions I've worked with (e.g. nixos) have a wrapper for gcc
and clang that just enforce the flags they want the distro to be built
with -- I don't think debian has anything like that, would that be
easier to work with? My line of thinking is that there will only be a
single place to fix instead of configure/cmake/meson and all hand-made
build scripts that exist around here.
Alternatively this would be delaying things even further to get a new
glibc version, but have a glibc build option that just makes this the
default and rebuild that debian repo with it?
afaik that's what musl has done in commit 38143339646a ("switch all
existing 32-bit archs to 64-bit time_t"):
https://git.musl-libc.org/cgit/musl/commit/?id=38143339646a4ccce8afe298c34467767c899f51
Ultimately (after year 2038), building without the option would be
meaningless and there really should be a way to enable it by
default. There will ALWAYS be build systems that ignore your new target
and we would basically be breaking all of these....
I really think this should/could probably be discussed first; there
shouldn't be THAT many packages breaking once gcc/glibc/etc compile,
but if we cannot reach an agreement on how to enforce this option there
really is no point.
(I didn't add libc-alpha to this mail, but happy to start over with them
in the loop)
> I don't think we can solve this problem now, but should
> postpone the inevitable debate about this until someone has done
> the work of rebootstrapping a working armhf environment with the
> current names.
>
> I don't expect that I'll have time to do this myself, but I'm
> happy to help someone else figure out how to get to that point.
I totally understand, thanks for all the work and the quick reply.
(I'll report back if I can allocate some time to help consistently, but
don't hold your breath on that)
--
Dominique
