2.1. Host Resources and Readiness

Before the build begins, the host system must provide the required development tools and should be verified. This section combines the host resource requirements with the readiness checks used to confirm that the machine can actually begin the build.

Required host tools: a POSIX-compatible shell, a working C and C++ compiler, git, gzip, awk, a yacc-compatible parser generator, CMake, Meson, rustc, cargo, and rsync.

The build described in this book assumes that the host environment is already capable of building nontrivial software. The host system is not expected to match the final target system, but it must be sufficiently complete to configure source trees, compile code, and run the build systems used by the packages in the early chapters.

A usable sh implementation is required for basic scripting and package build logic. Many configure scripts, bootstrap steps, and helper tools assume the presence of a POSIX shell and will fail immediately or behave incorrectly when the shell is absent or nonconforming. The exact implementation is less important than correctness.

The host must also provide a working C and C++ compiler. This requirement is fundamental. The compiler does not need to match the toolchain ultimately produced by the book, but it must be reliable enough to build the initial stages of the LLVM-based stack. A broken or partially functional compiler will produce misleading failures later in the process, where diagnosis is significantly harder.

CMake is required because several components in the LLVM ecosystem use it as their primary build system. Without CMake, the bootstrap path stops early. The version available on the host should be recent enough to support the LLVM release being built; using an arbitrarily old version is an efficient way to introduce avoidable configuration errors.

Meson is also required. A growing number of modern packages use it for configuration and build orchestration, and it is part of the expected toolset for a contemporary source-based environment. Its absence is not theoretical; it will block real packages needed to assemble a usable system.

The host should also provide Rust's core build tools: rustc and cargo. They are increasingly required by modern developer tooling and by packages that include Rust components even when the larger project is not primarily written in Rust. If either is missing, the build eventually stops in a much less entertaining place.

git and gzip are required by the source staging helper when a manifest entry points at a pinned upstream git commit instead of a release tarball. awk and a yacc-compatible parser generator are required by small userland packages that generate build-time source files.

rsync is also required. Section 5.1 (Linux API headers) uses it to copy header trees predictably while preserving metadata.

clang, and ninja, are not strictly required, but they are common tools that can be used to speed up the build process. If they are available, the build scripts will use them automatically. If they are missing, the build will fall back to more basic tools like gcc and make, which may be slower but still functional.

Common Host Package Sets

On most distributions, the fastest way to assemble a usable host is to start from the distribution's standard development meta-package or package group, then verify the exact tools required by this book. These package sets are starting points, not guarantees.

These package sets usually provide a compiler, linker, libc development files, make, awk, and part of the classic build stack. They do not always include everything needed here. In particular, cmake and meson are often missing from older or more conservative development groups, yacc-compatible parser generators may be packaged as byacc or as a yacc command provided by another package, and the Rust toolchain is frequently packaged separately.

For that reason, the host should still be checked explicitly even after the distribution meta-package is installed. If the package set is incomplete, add the missing tools individually and rerun the readiness checks.

Provided scripts: one implementation each for sh, zsh, and fish. All three check shell availability, required tool presence, C and C++ compilation, and basic linking.

These scripts are intended to be run on the host system before following the rest of the book. They perform four categories of checks.

The scripts are available at the following paths:

Each script prints a pass or fail result for every check and exits with a nonzero status if any requirement is missing or any compile or link test fails. The checks are intentionally small. The goal is not to exhaustively validate the host system; the goal is to detect obvious blockers before the real build starts.

If one of these scripts fails, fix the host first. Continuing with a broken shell, incomplete toolchain, or missing build system only turns a simple prerequisite problem into a harder diagnostic problem later.

The sh script is the baseline implementation and should work on any reasonably POSIX-conforming system. The zsh and fish variants exist for users who prefer to run the readiness check from their normal interactive environment without translating syntax by hand.

Other utilities will be introduced as needed in later chapters, but the list above establishes the baseline. If the host cannot provide a shell, a functioning compiler, and the build systems named here, it is not ready to begin bootstrapping.