On Mon, Oct 21, 2024 at 9:53 PM Samuel Thibault <samuel.thiba...@gnu.org> wrote: > Ah ok. > > Yes :)
Good :) > He said we was using > > https://mail.gnu.org/archive/html/bug-hurd/2023-01/msg00132.html I admit I didn't follow the link in the original message... Those are my notes about bootstrapping a toolchain & cross-compiling Mach/Hurd/glibc from a foreign system, specifically it was Fedora Linux, so neither a Debian system nor "an existing Hurd". Zhaoming, if you do follow my cross-compiling/bootstrapping notes, you should have the latest gnumach sources (including headers). Perhaps you're accidentally building with the native compiler and not a cross-compiler, so it looks for headers in /usr/include and not $PREFIX/include? Perhaps ./configure has figured out that the native (build) triplet matches the host triplet, and just decided to use system versions of the various tools? (Does it do that? I have no idea.) But yes, if you are on an existing GNU/Hurd system (of a matching architecture, since we have multiple of those now!), you shouldn't have to do the whole bootstrapping & cross-compilation dance. Just install up-to-date versions of gcc/binutils/mig/gnumach-dev from the system packages (on Debian, something like 'apt build-dep hurd' should get you all of those, and more), and do a plain './configure && make' in the Hurd repo, without any of the cross-compilation stuff. Just like you'd normally build any other project. Sergey
