[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
64bit support news
From: |
Samuel Thibault |
Subject: |
64bit support news |
Date: |
Thu, 1 Aug 2024 00:14:35 +0200 |
User-agent: |
NeoMutt/20170609 (1.8.3) |
Hello,
It's high time to give some updates on the 64bit front.
Things seem to be going quite nicely, there is of course still some work
ahead :)
The shell replacement issue that I was having is mostly understood now
and fixed/worked around ; there are two issues, found by Luca:
- The clobber structure
https://sourceware.org/git/?p=glibc.git;a=blob;f=hurd/intr-msg.c;h=424c1fc700a7c56f346d72eddf2c3e717d8ba28f;hb=HEAD#l42
was not large enough: with the pointer-size alignment on message
filling, restoring error_t was not large enough.
- The save_data structure
https://sourceware.org/git/?p=glibc.git;a=blob;f=hurd/intr-msg.c;h=424c1fc700a7c56f346d72eddf2c3e717d8ba28f;hb=HEAD#l70
happens to get saved in the xmm0 register instead of the stack, and sse
registers are not currently saved/restored by the signal management. In
Debian I added a volatile qualifier to work around the issue for now,
but saving/restoring sse registers needs to be implemented.
With that fixed/worked around, I was not seeing erroneous configure
executions etc. any more, so I was able to unleash the hurd-amd64 build
daemon, which has been busy building packages for a couple of weeks now,
we have ~2600 installed packages now, and as many in buildable state,
and yet more to come after that by dependency.
I was able to bootstrap rust, which was important to e.g. get
gstreamer1.0 built. I have not managed to bootstrap ghc yet, it's
currently broken upstream in 9.4, and 9.0 also fails for me.
We are then seeing build failures, see
https://people.debian.org/~sthibault/hurd-amd64/failed.txt
There are various categories:
- packages that don't fail on hurd-i386, probably worth investigating as
that'll probably reveal some bugs in the hurd-amd64 port.
- packages that also fail on hurd-i386, no surprise here. In some
cases (to unlock other packages by dependency), it can be useful to
investigate which older version was previously not failing on hurd-i386,
and I can build&upload that to the unreleased distribution. I have done
so for some packages already.
- packages that didn't fail on hurd-i386 when it was tried,
but that nowadays do fail on hurd-i386 too. Unforunately,
notably we currently have a Debian switch to gcc-14, and
implicit-function-declaration-errors, which produces various new
failures to build due to the increased hardening on compiler warnings
(no bogus pointer casting allowed, no implicit function declaration).
- packages that not only fail on hurd-amd64 and hurd-i386, but also
amd64/i386 (quite often gcc-14 & implicit-func issues again). Probably
not worth spending time on this and let other people have a look.
I'm currently having a look at mariadb, which is essential for many
dependencies.
I have noticed that the ibus package errs out in its testsuite. ibus is
a dependency for e.g. libsdl2 and thus a lot of packages, could somebody
take a look at its testsuite failures?
Thanks for the collective work on this!
Samuel
- 64bit support news,
Samuel Thibault <=