Cross-Compiler-to-Self-Host Handoff¶
Handoff procedure — instantiates Self-Hosted Bootstrap Construction
Uses a foreign compiler to produce the first native build on a new platform, then hands construction to that build so the system compiles itself — and retires the foreign compiler.
When a system must run somewhere it has never run before, it cannot yet build itself there — something else has to produce the first copy. Cross-Compiler-to-Self-Host Handoff is the procedure that borrows a foreign builder running on a host platform to emit the first working artifact for the target, then transfers construction to that artifact so the system begins compiling itself on its own platform — and, crucially, retires the borrowed builder once the self-hosted path is proven. Its defining move is the one-directional handoff across a platform gap: the foreign compiler is a temporary bridge that exists only to get a native foothold, and the procedure is not finished until authority has passed to the self-hosted build and the bridge has been removed from the trusted path. It is the moment a port stops depending on where it came from.
Example¶
An engineering team brings up a compiler toolchain on a fresh CPU architecture — a new RISC-V board with nothing on it. On an existing x86 host they configure the compiler to cross-compile: the host's compiler builds a version of the toolchain that emits code for the new chip. That cross-built toolchain is copied to the board and used to compile the compiler's own source on the board, producing a fully native build — the first artifact the target made of itself. Following the shape of a multi-stage compiler bootstrap, they then have that native build compile the source once more and confirm the result matches, evidence that self-hosting is stable rather than a fluke of the cross environment.
With the native, self-reproducing toolchain in hand, the handoff completes: the board's own build becomes the authoritative source of future toolchains, and the x86 cross-compiler is retired from the trusted path — kept only as archived history, never again a live dependency. The port is now genuinely self-hosted; nothing about x86 is load-bearing anymore.
How it works¶
What distinguishes this procedure is that it manages a platform discontinuity and then closes it. The foreign compiler serves as a compatibility bridge spanning host and target, used solely to manufacture the first native build; construction is then handed to that build under an explicit rule that self-hosting is only declared once the native toolchain reproduces itself on its own platform. The final, non-optional step is retirement: the bridge is removed from the live dependency path so the system's independence is real rather than nominal. Skipping any of the three — bridge, handoff, retirement — leaves either no foothold, no transfer, or a permanent hidden crutch.
Tuning parameters¶
- Bridge fidelity — how closely the cross environment must mimic the target (ABI, word size, endianness, libc). Higher fidelity reduces first-native surprises but is harder to set up; a loose bridge boots faster but risks a native build that behaves subtly differently.
- Handoff proof — how much self-reproduction is required before declaring self-hosting (one native build, or a native build that rebuilds itself and matches). Stronger proof is more convincing but costs extra build rounds.
- Retirement timing — how soon the foreign builder leaves the trusted path after handoff. Early retirement forces genuine independence sooner; a longer grace period keeps a fallback but risks the crutch quietly becoming permanent.
- Archival policy — whether the retired bridge is kept as reproducible history or discarded. Keeping it aids future audits and re-ports; discarding it saves space but can strand a later investigation.
When it helps, and when it misleads¶
Its strength is that it is the only clean way onto a platform the system cannot yet inhabit, and it converts a scary all-at-once port into a defined sequence with a clear finish line — self-hosting is declared, on evidence of self-reproduction, not assumed. The mandatory retirement step is what keeps a "temporary" cross-compiler from silently becoming forever.
Its failure mode is a bridge that never leaves: teams reach self-hosting, then keep quietly building through the cross-compiler because it is convenient, so the platform independence they claim is fictional and the foreign toolchain's quirks keep leaking in. A subtler trap is a native build that inherited a defect from the cross environment yet passes a shallow "it compiled" check. The classic misuse is declaring the handoff done at first successful native compile, before confirming the build actually reproduces itself. The discipline is to gate the handoff on demonstrated self-reproduction and to treat bridge retirement as part of "done," not an optional cleanup.[1]
How it implements the components¶
Cross-Compiler-to-Self-Host Handoff fills the archetype's platform-transfer components — bridge on, hand over, bridge off:
compatibility_bridge— the foreign compiler spanning host and target is the temporary bridge that manufactures the first native build.steady_state_handoff_rule— it defines the condition (self-reproduction on the target) under which authority passes from the foreign builder to the self-hosted build.bootstrap_artifact_retirement_rule— it removes the foreign compiler from the trusted path once self-hosting is proven, so independence is real.
It does not plan the rung sequence being ported (that's Capability-Ladder Runbook), replace external tools incrementally on a platform already reached (that's Bootstrap Toolchain Pin-and-Replace), or prove the native build matches the cross build bit-for-bit (that's Diverse Double-Compilation Check and its equivalence-testing siblings).
Related¶
- Instantiates: Self-Hosted Bootstrap Construction — this procedure carries the system across a platform gap and into genuine self-hosting.
- Consumes: Capability-Ladder Runbook — the ladder tells the handoff which capabilities the native build must reach before authority can pass.
- Sibling mechanisms: Bootstrap Toolchain Pin-and-Replace · Diverse Double-Compilation Check · Capability-Ladder Runbook · Checkpointed Stage Promotion · Clean-Environment Rebuild · Staged Self-Host Build · Post-Bootstrap Artifact-Retirement Audit
References¶
[1] A multi-stage compiler bootstrap (build the compiler, use it to rebuild itself, then rebuild once more and require the last two outputs to match) is the standard way to show a self-built toolchain is stable and independent of the environment that seeded it — the self-reproduction evidence this handoff gates on. ↩