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
