Arnd did a superb recap in 2020, let me just link to it first in case anyone needs a reminder:
https://lists.debian.org/debian-arm/2020/02/msg00024.html
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?
From what I can tell, the main thing that has changed is that thereis even less developer time that we can spend on armhf. With every
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...)
(It was Steve who did the recap of the work that I had done)
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.
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.
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.
Arnd Bergmann wrote on Wed, Sep 28, 2022 at 08:21:00AM +0200:
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
...
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.
As far as I'm aware, there haven't been any new public discussion since
that 2020 thread
I won't bring anything very useful to the table here: I'd be happy to
give some limited time,
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?
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. 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.
On Wed, Sep 28, 2022 at 3:24 AM Dominique MARTINET <dominique.martinet@atmark-techno.com> wrote:
...
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.
Debian has dpkg-buildflags . Discussions about it show up when
discussing hardening, like [0].
[0] https://wiki.debian.org/Hardening#dpkg-buildflags
On 2022-09-28 09:32 -0400, Jeffrey Walton wrote:
On Wed, Sep 28, 2022 at 3:24 AM Dominique MARTINET
<dominique.martinet@atmark-techno.com> wrote:
...
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.
Debian has dpkg-buildflags . Discussions about it show up when
discussing hardening, like [0].
[0] https://wiki.debian.org/Hardening#dpkg-buildflags
Right, and just changing it and rebuilding works very well. I did this
for PAC (pointer authentication) support last year. Very few packages
do not correctly honour dpkg-buildflags.
In fact the only issue was that I unconditionally changed it so it got
issued by some packages (like migw) for the wrong-arch compiler
(because they were cross-building). One should be a bit smarter to unconditionally set an _arch-specific_ flag.
dpkg-buildflags has functionality for this. See patch at bottom of: https://lists.debian.org/debian-dpkg/2022/05/msg00022.html
Presumably the 'use 64-bit time_t' flag is the same for all arches,
but may only exist on 32-bit arches?
On 2022-09-28 11:09 +0900, Dominique MARTINET wrote:
As far as I'm aware, there haven't been any new public discussion since
that 2020 thread
I mentioned it in the 'arm status' talk at debconf this year.
-- has there been any new attempt I missed?
I have been planning for a while to have a go at a bootstrap but have
not actually done anything yet. It is rising up my list as 'most
important task' (currently after 'fixing porterbox abel').
It would be nice to do it within the armhf archive but although we
have mechanisms for core library transitions (like we did for libc5 to
6) a) this affects all arches so is a lot of churn for an issue only affecting one arch (or maybe all 32-bit arches, but I'm not sure how
many of those other than arm (v7) will be around much longer?
So that might be the first thing to think about again?
A new debian arm ABI arch is definitely the easiest way to do this, as
Arndt says. Having thought about it a bit, I suggest we just call
it 'arm32' as in the future it will be useful to distinguish legacy
32-bit arm from arm64 (and maybe armv9 or whatever variants come in the future). And having just 'arm32' and 'arm64' arches will be quite
pleasing for however long it lasts.
Obviously bikeshedding about the name and triplet is the least
important part of this.
Andt Bergman wrote:
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. 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.
Agreed. And this was my plan. Just so we can check that stuff
basically works before patching toolchain builds. Given that arch have
it working it should be (?) as simple as setting some flags and
doing a rebuild (and fixing whatever breaks).
On Thu, Sep 29, 2022, at 2:14 AM, Wookey wrote:
I think the problem with using dpkg-buildflags is that it breaks
any user building their own applications against Debian provided
libraries, unless they remember to set the flag manually.
The flag is -D_TIME_BITS=64, and this can be set unconditionally
everywhere if that helps. Note that this implies -D_FILE_OFFSET_BITS=64,
i.e. you can't have 64-bit time_t without 64-bit off_t/ino_t/...
As far as I understand, there are still a few libraries in Debian
that are built with 32-bit off_t in order to not break the traditional
ABI,
So with time64, there will be an ABI change both for the few
libraries that are currently using 32-bit off_t in addition to
those that use time_t/timeval/timespec
This is also going to be hard for non-C languages with C bindings
(python, rust, ...) that have structure types hardcoded.
On Thu, Sep 29, 2022, at 11:49 AM, Wookey wrote:
On 2022-09-29 09:47 +0200, Arnd Bergmann wrote:
I think the problem with using dpkg-buildflags is that it breaks
any user building their own applications against Debian provided
libraries, unless they remember to set the flag manually.
Yes, but I'm talking about how to do a test rebuild. We set the dpkg-buildflags config to always use -D_TIME_BITS=64 in the build
chroot, and build stuff.
Right, that should work. In my 2020 experiment I did the opposite
and actually patched glibc to remove the time32 interfaces so
I could be really sure that everything would use the time64
path, but clearly at least the core packages all use the
buildflags correctly.
Are you aware of anyone else having written up efforts around this
(e.g. if the arch people have changed it already they presumably found
a load of the things one might trip over).
Adelie Linux has (had?) a great summary. I can't reach the wiki page
at the moment, but I found an archive copy at
https://web.archive.org/web/20220301175235/https://wiki.adelielinux.org/wiki/Project:Time64
On 2022-09-29 09:47 +0200, Arnd Bergmann wrote:
On Thu, Sep 29, 2022, at 2:14 AM, Wookey wrote:
I think the problem with using dpkg-buildflags is that it breaks
any user building their own applications against Debian provided
libraries, unless they remember to set the flag manually.
Yes, but I'm talking about how to do a test rebuild. We set the dpkg-buildflags config to always use -D_TIME_BITS=64 in the build
chroot, and build stuff.
Hmm. Yes that could be interesting.
Are you aware of anyone else having written up efforts around this
(e.g. if the arch people have changed it already they presumably found
a load of the things one might trip over).
On 2022-09-29 10:10 +0200, Arnd Bergmann wrote:
...
I know are Alpine Linux, Adelie Linux and OpenWRT, but those all
use musl-1.2, not glibc, and they have a much smaller set of packages.
OK. We still have plenty of bugs to find then :-)
Wookey
On Thu, Sep 29, 2022 at 10:53:21AM +0100, Wookey wrote:
On 2022-09-29 10:10 +0200, Arnd Bergmann wrote:
...
I know are Alpine Linux, Adelie Linux and OpenWRT, but those all
use musl-1.2, not glibc, and they have a much smaller set of packages.
OK. We still have plenty of bugs to find then :-)
Such bugs have already been found, reported and fixed in Debian for
10 years thanks to the x32 port (e.g. #700012).
More than 13k packages are currently Installed on x32 after having been natively built and (if they have) passing their build time tests.
On Sun, Oct 2, 2022, at 1:59 PM, Adrian Bunk wrote:
On Thu, Sep 29, 2022 at 10:53:21AM +0100, Wookey wrote:
On 2022-09-29 10:10 +0200, Arnd Bergmann wrote:
...
I know are Alpine Linux, Adelie Linux and OpenWRT, but those allOK. We still have plenty of bugs to find then :-)
use musl-1.2, not glibc, and they have a much smaller set of packages. >>
Such bugs have already been found, reported and fixed in Debian for
10 years thanks to the x32 port (e.g. #700012).
More than 13k packages are currently Installed on x32 after having been natively built and (if they have) passing their build time tests.
There is a minimal user base on x32, so I'm sure a lot of bugs
have gone unnoticed. Having 64-bit time_t on BSD and Windows
probably did more to find bugs, but there are still lots of
issues where neither of this would help. For instance:
...
- Things that are written in a language other than C/C++
but don't link to C libraries should keep working,
but
will not be y2038 safe unless they also migrate to the
time64 interfaces by copying what glibc did.
...
...
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. 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.
...
On Sun, Oct 2, 2022, at 1:59 PM, Adrian Bunk wrote:
More than 13k packages are currently Installed on x32 after having been natively built and (if they have) passing their build time tests.
There is a minimal user base on x32, so I'm sure a lot of bugs
have gone unnoticed. Having 64-bit time_t on BSD and Windows
probably did more to find bugs, but there are still lots of
issues where neither of this would help. For instance:
- Any applications that use direct system calls with a 32-bit
time_t have to change to the correct replacement syscall.
This never had to be done on x32, because there is only one
such set of syscalls. A number of upstream packages already
got fixed for riscv32, but unfortunately some of those were
done in a way that is still broken for architectures that
have both the time32 and time64 versions.
Most commonly, this affects __NR_futex/SYS_futex, but there
are other syscalls needed elsewhere
- Libraries using input_event structures on /dev/input/*
need to have an updated copy of the kernel headers. Most
upstream packages do now, but I'm sure there are some left.
- Packages that rely on seccomp have to be updated to
allow both the old and new versions of system calls in their
whitelists
- Anything that is written in a language other than C but
links to C libraries needs to be updated to use the new
data structure definitions. Some of these may have a special
case for x32, or they are just wrong. There are a lot of
python or rust libraries affected by this, and no obvious
answer.
- Things that are written in a language other than C/C++
but don't link to C libraries should keep working, but
will not be y2038 safe unless they also migrate to the
time64 interfaces by copying what glibc did.
- Any package that currently relies on having a 32-bit
off_t/ino_t will break after being forced to update to
the 64-bit version, even if they don't care about
time_t.
- Packages may hardcode the time_t/timeval/timespec
definition. If they use __kernel_long_t, they would
even work on x32, but break on any other 32-bit ABI.
Arnd
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 488 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 07:27:17 |
| Calls: | 9,663 |
| Calls today: | 5 |
| Files: | 13,711 |
| Messages: | 6,167,018 |
| Posted today: | 2 |