Hello folks, Thanks for all the emails.
The flavor I'm running is hurd-i386 which came with the pre-installed debian-hurd-20230608.img. I am just cloning the repo. Trying to rebuild it for 32 bit, and stick it inside the /boot folder, and then change grub.cfg minimally to take my (just built and copied) gnumach.gz instead of the default one that comes preinstalled with Debian. I don't touch anything else there! Basically this is all as pristine as it comes. Debian-hurd unaltered (except from git, texinfo, and some other things installed). Unaltered gnumach repo, and unaltered mig repo. As far as CFLAGS go on my host linux Arch and also on my Debian-Hurd: $ echo $CFLAGS (empty) Nothing prints out. They are not set, other than what the unaltered Makefile sets them. Here is the config.log <https://justpaste.it/gg2af> from Debian-Hurd Here is the config.log <https://justpaste.it/fya16> from Arch Host . As far as that "n", I have no idea where that is coming from. It's not happening when I try on the Host, only inside Hurd. I see in the Makefile there is a line such as: MIGCOM = $(MIG) -n -cc cat - /dev/null That looks a lot like: n -cc cat - /dev/null -user ./tests/mig-out/device.user.c -header ./tests/mig-out/device.user.h -list ./tests/mig-out/device.user.msgids < ./tests/mig-out/device.user.defs That I see in logs. So it would mean $(MIG) is evaluating to nothing. Yet there is this up there in the file: MIG = mig And mig is present on the system. I also tried rebuilding gnumach where i didn't pass anything into ./configure while inside Hurd, it didn't change the outcome Thanks for looking into this. On Tue, Jun 17, 2025 at 5:48 AM <jbra...@dismail.de> wrote: > June 17, 2025 at 12:25 AM, "Milos Nikic" <nikic.mi...@gmail.com mailto: > nikic.mi...@gmail.com?to=%22Milos%20Nikic%22%20%3Cnikic.milos%40gmail.com%3E > > wrote: > > > > > > > Hello > > > > Thanks folks, I appreciate any help you guys can provide. > > > > Yes I used the pristine gnumach and mig. Just cloned and pulled again > today. > > If you still can't figure it out, ask on #hurd. I believe damo22 and > solid_black > cross compile the Hurd. They are two prominent hurd developers. > > I believe our fearless leader developers the hurd the "Debian way". > > > I compiled gnumach on my Linux Arch (cross compiled?). With a script > from compile-scratch.sh > https://github.com/AlmuHS/gnumach_dev_scripts/blob/main/compile_scratch.sh > > Then I ran > > $ make tests/test-task.iso (from my build directory). > > The thing didn't even compile correctly: > > > > /usr/bin/ld: /tmp/ccYq0CRM.o: in function `test_task': > > > /home/user/Projects/hurd/gnumach/build/../tests/test-task.c:57:(.text+0x27e): > undefined reference to `__stack_chk_fail_local' > > > > Full log: https://justpaste.it/k3rvq > > > > Mig is present: > > $ which mig > > /home/user/gnu/bin/mig > > $ mig --version > > i686-gnu-mig (GNU MIG) 1.8 > > > > And inside hurd it looked like this: > > > > $ cd gnumach > > $ git fetch origin > > $ git reset --hard origin/master > > $ autoreconf -i > > $ mkdir build > > $ cd build > > $ ../configure --host=i686-gnu CC='gcc -m32' > > $ make gnumach.gz > > $ make tests/test-task.iso > > Lots of errors, such as: > > ../tests/test-task.c:28:10: fatal error: gnumach.user.h: No such file or > directory > > 28 | #include <gnumach.user.h> > > > > Full output https://justpaste.it/eug2i : > > > > Mig is present: > > $ which mig > > /usr/bin/mig > > $ mig --version > > mig (GNU MIG) 1.8 > > > > Apologize for the details, I highly suspect that I am doing something > wrong here. > > Thanks in advance. > > > > On Mon, Jun 16, 2025 at 6:39 PM Diego Nieto Cid <dnie...@gmail.com > mailto:dnie...@gmail.com > wrote: > > > > > > > > Hello, > > > > > > On Mon, Jun 16, 2025 at 08:10:13AM -0700, Milos Nikic wrote: > > > > Hello, > > > > > > > > Thanks for the email. > > > > The thing is I am not cross compiling. I am instead compiling from > inside > > > > Hurd (in Qemu). > > > > Yet cannot seem to get it quite right (even though it compiles > > > > successfully inside Hurd, when I copy it to /boot it panics on the > next > > > > reboot). > > > > > > > > > > The pristine gnumach sources should work. You can check whether it's a > bug or > > > just a configuration issue by running the test suit. > > > > > > For instance, you can build the task tests with the following command > from > > > your build tree: > > > > > > $ make tests/test-task.iso > > > > > > You can then run the test from a GNU/Linux box (after copying over the > iso file) > > > by running the ISO in quemu: > > > > > > $ qemu-system-x86_64 -m 2048 -nographic -no-reboot -boot d -cdrom > test-task.iso > > > > > > It will book QEMU and produce some output and the following line at > the end: > > > > > > gnumach-test-success-and-reboot: test module-task exit code 0 > > > > > > Keep us updated of how it goes :) > > > > > > Cheers, > > > Diego > > > > > >
