64bit support news

[Samuel Thibault]

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