June 17, 2025 at 8:18 PM, "Milos Nikic" <nikic.mi...@gmail.com mailto:nikic.mi...@gmail.com?to=%22Milos%20Nikic%22%20%3Cnikic.milos%40gmail.com%3E > wrote:
> > Hello folks, > > Thanks for all the emails. I've never really gotten the hang of "hacking" on the Hurd / GNU Mach / MiG, etc. Sergey wrote these two guides on how to cross compile the Hurd. Basically you run GNU/Linux on bare metal. Then you build the Hurd from your Linux box, and run the Hurd via qemu: Maybe these guides will help you a little bit. I'd link you to the website, but that seems to be down at the moment... https://lists.gnu.org/archive/html/bug-hurd/2024-09/msg00051.html https://lists.gnu.org/archive/html/bug-hurd/2024-09/msg00052.html > 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 mailto:jbra...@dismail.de > > wrote: > > > > > June 17, 2025 at 12:25 AM, "Milos Nikic" <nikic.mi...@gmail.com > > mailto:nikic.mi...@gmail.com mailto:nikic.mi...@gmail.com > > mailto:nikic.mi...@gmail.com > > ?to=%22Milos%20Nikic%22%20%3Cnikic.milos%40gmail.com http://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 mailto: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 > > > > > > > > > >
