Cross-compilation

Cross-compilation separates the place where software is built from the place where it will execute. A compiler running on an x86-64 workstation may emit machine code for ARM, RISC-V, WebAssembly, or an operating system different from the workstation’s own. The output is not necessarily portable source code: it is usually a binary or object file for a specified target architecture, operating system, and application binary interface (ABI).¹

The distinction is especially useful when the target is slow, resource-constrained, newly manufactured, or incapable of running a development environment. Firmware for microcontrollers, packages for another processor family, and boot components are commonly built this way. A related but distinct case is Canadian cross, in which the machine running the compiler, the machine on which the compiler runs, and the machine for which it produces code are all different.

A successful cross-build requires a toolchain whose components agree about the target. The compiler generates target instructions; the assembler and linker create target object files and executables; and target-specific headers and libraries provide the interfaces expected by that executable.¹ Tool names often encode a target triple, such as architecture, vendor, and operating-system components, although the exact spelling and interpretation vary.

The sysroot supplies a directory tree treated as the target system’s root, allowing headers and libraries to be selected without accidentally using host files. The target’s C library, startup objects, dynamic loader, calling convention, floating-point rules, and ABI must match the generated code. GNU toolchains and LLVM-based toolchains provide different mechanisms for selecting these resources, but the underlying requirement is the same: compilation and linking must resolve target resources consistently.⁵

Build systems need explicit target information because configuration tests cannot assume that compiled programs can run on the build machine. GNU Autoconf distinguishes the build, host, and target systems and can use precomputed results for tests that cannot be executed during a cross-build. CMake instead commonly receives a toolchain file that identifies compilers, search paths, platform names, and whether generated target programs may be run during configuration.²

A practical workflow installs or constructs a target toolchain, selects a matching sysroot, configures the project for the target, compiles and links it, then transfers the result to an emulator, board, device, or test machine. Host utilities needed during the build must remain host executables; confusing them with target binaries is a frequent failure mode. Package managers can also provide parallel libraries and headers for several architectures, as in Debian Multiarch.³

Cross-compilation is not limited to changing a compiler flag; the hardest problems often occur at the boundaries between build phases. A project may compile correctly but fail at link time because its libraries use a different ABI, or it may produce a valid binary that cannot start because the target dynamic loader is absent or located differently. Static linking can reduce runtime dependencies, but it introduces licensing, size, and compatibility considerations.

Some projects use emulation, such as QEMU, to run target programs during tests, but emulation can be slower and may not reproduce device peripherals or timing. Bare-metal targets may have no operating system, filesystem, or C library at all, so the toolchain links against a board-specific runtime and linker script. Conversely, reproducible builds require controlling host-dependent paths, timestamps, and tool versions so that separate machines produce equivalent target artifacts. LLVM documents cross-compiling as a configuration involving target selection, libraries, and runtime support rather than merely source translation.

Host

The platform on which the compiler and build process run.

Target

The platform for which the generated program is intended.

Target triple

A conventional identifier describing major target properties such as architecture, vendor, and operating system.

Sysroot

A directory treated as the target system’s root for locating headers, libraries, and related files.

ABI

The binary-level rules governing interfaces such as calling conventions, data layouts, and linking.

Canadian cross

A build arrangement in which the build machine, compiler-running host, and generated-code target are three distinct platforms.