Toolchain bootstrap

A source distro that seeds its compiler is a lie wearing a costume. Keru's stage 0 builds the toolchain from nothing — the assembler, the compiler, the C library, then a self-hosted toolchain package — before a single package in your system tree is compiled.

Why the order matters

Step	What runs	Why first
1	`binutils`	as, ld, ar — you can't compile without an assembler and linker.
2	a bare `gcc`	The C compiler, built against nothing but binutils.
3	your `libc`	glibc, musl, or uclibc-ng. Everything userspace depends on it.
4	a full `gcc`	Re-built now that the target libc exists (self-hosting).
5	`toolchain` package	Freezes the whole toolchain as a kama package for the rest of the build.

A bootstrap run

$ sh scripts/build-root.sh

[ keru ] stage 0: bootstrap toolchain
[ keru ]   binutils 2.42        ... ok
[ keru ]   gcc 13.2 (bare)     ... ok
[ keru ]   glibc 2.39          ... ok
[ keru ]   gcc 13.2 (self)     ... ok
[ keru ]   toolchain → ROOT    ... ok
[ keru ] stage 1: base system

Where it goes wrong

libc switch. Bootstrapping against musl or uclibc-ng rearranges the early stages; the exact package set lives with the libc page. A combo that isn't proven yet gets a warning — never a silent block.
Host leakage. Everything must link against the freshly built chain, not the build host's. The recipes pass explicit --host/--target and CC/CFLAGS so nothing sneaks in.
Double-build cost. gcc is compiled twice by design. That's the price of honesty; it's also a warm-up for the rest of the arch.

This is the line Keru draws: before your base system, a full self-hosting toolchain exists that didn't exist before. After that, the rest is just — as one long build script — more of the same.

← Security · Build pipeline