🎉 🎉 🎉
start ext2fs: Hurd server bootstrap: ext2fs[rd0] exec
Cannot find startup program `hurd/startup': No such file or directory
ext2fs: ../../libdiskfs/boot-start.c:274: diskfs_start_bootstrap: Unexpected error: No such file or directory.
🎉 🎉 🎉
start ext2fs: Hurd server bootstrap: ext2fs[rd0] exec
Cannot find startup program `hurd/startup': No such file or directory
ext2fs: ../../libdiskfs/boot-start.c:274: diskfs_start_bootstrap: Unexpected error: No such file or directory.
It basically all works --
pthreads, dynamic linking, the file system, libdiskfs, librtivfs, libports, libpager / userspace-implemented memory objects (take that, XNU!).
It only doesn't proceed with booting further because I haven't put /hurd/startup into the initrd.
This is ld.so starting up in the second bootstrap task (future exec server!) after having successfully done an RPC to the first bootstrap task (ext2fs)!!
And that of course means the SHARED glibc build also works at least somewhat 🙂
As of today, the x86_64-gnu port of glibc is fully and officially upstream! 🎉
You can build it by fetching the latest Git master and running
$ ../configure --host=x86_64-gnu && make
(If you want to actually *run* it on today's GNU Mach, you'll need to apply a little patch: change BRK_START in x86_64/vm_param.h to 0x20000000)
Next up: seeing what it would take to build and run the Hurd itself! I already have the core libraries and servers building.
Q: how do I explicitly call std::string's destructor? `str.~std::string()` doesn't compile.
A: `str.~basic_string()`
I'm really getting to a point where I can see all of glibc building on x86_64-gnu in not-so-distant future (several hacking sessions away from now)
Of course "building" and "working" are different things...
trampoline.c compiles! ?
Ok, now I will
goto sleep;
COMEFROM sleep;
In fact, I wonder how far we could get without trampoline/intr-msg/signal stuff really working. Signals are not expected to work in early userspace, and none of the kernel calls we'd want to make (task and memory manipulation, opening and writing to Mach console, etc) are interruptible anyway.
$ readelf -h ~/dev/crosshurd64/src/glibc/build/elf/ld.so | head
ELF Header:
Magic: 7f 45 4c 46 02 01 01 03 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - GNU
ABI Version: 0
Type: DYN (Shared object file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
? ld.so builds!! ?
Oh look, someone on SO is asking for (nearly) the exact thing I wrote before: a glibc-less "Hello world" for the Hurd.
Should I send them the link to https://github.com/bugaevc/hello-hurd? ?
Except they want it to be short and in assembly, not C. Guess I could just dump the asm GCC generates? It would not even be _that_ long in the TINIER config.
Spent most of today trying to build myself a cross toolchain —
specifically, I want to compile binaries for GNU/Hurd from my GNU/Linux box. These are both GNU systems that are well supported in the upstream GNU projects, so this should have worked flawlessly, without a single hiccup, right?
Lol no ?
For starters, there are all the circular dependencies:
• GCC includes libgcc and so depends on glibc
• glibc of course cannot be built without GCC, and it also depends on MIG, as well as Mach and Hurd headers
• MIG depends on Mach too, for types & stuff
• Mach naturally needs GCC and MIG to be built
• The Hurd needs all four — GCC, MIG, Mach, and glibc.
Yay
But this can be worked around in a relatively not-so-terrible way:
• You build GCC proper, without libgcc
• Then you install some Mach headers without actually compiling anything
• Then you build MIG
• Now you can kinda compile the Hurd MIG defs, if you trick the build system into letting you build anything.
You do this by invoking CC=gcc ./configure --host=i686-gnu $OTHER_FLAGS — i.e., we're building for the Hurd, but do your stupid checks using my host toolchain for now so that we can pretend that everything works and at least get something done today
• After this, you can actually build enough of glibc to install its headers. You'll also have to build csu/crt[1in].o & manually copy them over into the prefix, and also create a couple of empty files (include/gnu/stubs.h & the very lib/libc.so!)
Why glibc doesn't do this automatically is beyond me, but I guess this is a small thing relative to everything else here
• Now you can finally go back to GCC and build libgcc
• Now you can build glibc for real, then Hurd, then whatever else remains.
Sounds like a breeze, doesn't it?
But anyways, *that* I have figured out. What I haven't is paths.
Simply speaking, I want my toolchain to intrinsically know where to look for (system) header files and libraries — in $PREFIX/include and $PREFIX/lib respectively — so that when I set CC=$PREFIX/bin/i686-gnu-gcc the right directories are picked up automatically, just like the system compiler picks up /usr/include and /usr/lib without me having to add them explicitly.
That doesn't sound like a very strange thing to want, does it?
In fact I'm almost positive that other cross toolchains I've worked with in the past have done just that.
But — I can't seem to be able to find the right combination of incantations. Between all the --prefix, DESTDIR, --with-sysroot, --with-byild-sysroot, --with-headers, --with-native-system-header-dir, something goes wrong. I was actually able to convince GCC to look for headers in the right place, but the libraries still escape me.
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.