Community hub
Recent from talks
Contribute something
Nothing was collected or created yet.
Cross compiler
View on Wikipedia| Program execution |
|---|
| General concepts |
| Types of code |
| Compilation strategies |
| Notable runtimes |
|
| Notable compilers & toolchains |
|
A cross compiler is a compiler capable of creating executable code for a platform other than the one on which the compiler is running. For example, a compiler that runs on a PC but generates code that runs on Android devices is a cross compiler.
A cross compiler is useful to compile code for multiple platforms from one development host. Direct compilation on the target platform might be infeasible, for example on embedded systems with limited computing resources.
Cross compilers are distinct from source-to-source compilers. A cross compiler is for cross-platform software generation of machine code, while a source-to-source compiler translates from one coding language to another in text code. Both are programming tools.
Use
[edit]The fundamental use of a cross compiler is to separate the build environment from target environment. This is useful in several situations:
- Embedded computers where a device has highly limited resources. For example, a microwave oven will have an extremely small computer to read its keypad and door sensor, provide output to a digital display and speaker, and to control the microwave for cooking food. This computer is generally not powerful enough to run a compiler, a file system, or a development environment.
- Compiling for multiple machines. For example, a company may wish to support several different versions of an operating system or to support several different operating systems. By using a cross compiler, a single build environment can be set up to compile for each of these targets.
- Compiling on a server farm. Similar to compiling for multiple machines, a complicated build that involves many compile operations can be executed across any machine that is free, regardless of its underlying hardware or the operating system version that it is running.
- Bootstrapping to a new platform. When developing software for a new platform, or the emulator of a future platform, one uses a cross compiler to compile necessary tools such as the operating system and a native compiler.
- Compiling native code for emulators for older now-obsolete platforms like the Commodore 64 or Apple II by enthusiasts who use cross compilers that run on a current platform (such as Aztec C's MS-DOS 6502 cross compilers running under Windows XP).
Use of virtual machines (such as Java's JVM) resolves some of the reasons for which cross compilers were developed. The virtual machine paradigm allows the same compiler output to be used across multiple target systems, although this is not always ideal because virtual machines are often slower and the compiled program can only be run on computers with that virtual machine.
Typically the hardware architecture differs (e.g. coding a program destined for the MIPS architecture on an x86 computer) but cross-compilation is also usable when only the operating system environment differs, as when compiling a FreeBSD program under Linux, or even just the system library, as when compiling programs with uClibc on a glibc host.
Canadian Cross
[edit]The Canadian Cross is a technique for building cross compilers for other machines, where the original machine is much slower or less convenient than the target. Given three machines A, B, and C, one uses machine A (e.g. running Windows XP on an IA-32 processor) to build a cross compiler that runs on machine B (e.g. running macOS on an x86-64 processor) to create executables for machine C (e.g. running Android on an ARM processor). The practical advantage in this example is that Machine A is slow but has a proprietary compiler, while Machine B is fast but has no compiler at all, and Machine C is impractically slow to be used for compilation.
When using the Canadian Cross with GCC, and as in this example, there may be four compilers involved
- The proprietary native Compiler for machine A (1) (e.g. compiler from Microsoft Visual Studio) is used to build the gcc native compiler for machine A (2).
- The gcc native compiler for machine A (2) is used to build the gcc cross compiler from machine A to machine B (3)
- The gcc cross compiler from machine A to machine B (3) is used to build the gcc cross compiler from machine B to machine C (4)
The end-result cross compiler (4) will not be able to run on build machine A; instead it would run on machine B to compile an application into executable code that would then be copied to machine C and executed on machine C.
For instance, NetBSD provides a POSIX Unix shell script named build.sh which will first build its own toolchain with the host's compiler; this, in turn, will be used to build the cross compiler which will be used to build the whole system.
The term Canadian Cross came about because at the time that these issues were under discussion, Canada had three national political parties.[1]
Timeline of early cross compilers
[edit]![[icon]](https://en.wikipedia.org/wiki/File:Wiki_letter_w_cropped.svg){kind=small} | This section needs expansion. You can help by adding to it. (July 2012) |
- 1969 –The first version of UNIX was developed by Ken Thompson on a PDP-7, but due to the lack of tools and cost, it was cross-compiled on a GECOS system and transferred via paper tape. This showed practical cross-compilation for OS development.[2]
- 1979 –ALGOL 68C generated ZCODE; this aided porting the compiler and other ALGOL 68 applications to alternate platforms. To compile the ALGOL 68C compiler required about 120 KB of memory. With Z80 its 64 KB memory is too small to actually compile the compiler. So for the Z80 the compiler itself had to be cross compiled from the larger CAP capability computer or an IBM System/370 mainframe.
- 1980s –Aztec C offered native and cross-compilation for home computers like Apple II and Commodore 64.
GCC and cross compilation
[edit]GCC, a free software collection of compilers, can be set up to cross compile. It supports many platforms and languages.
GCC requires that a compiled copy of binutils is available for each targeted platform. Especially important is the GNU Assembler. Therefore, binutils first has to be compiled correctly with the switch --target=some-target sent to the configure script. GCC also has to be configured with the same --target option. GCC can then be run normally provided that the tools, which binutils creates, are available in the path, which can be done using the following (on UNIX-like operating systems with bash):
PATH=/path/to/binutils/bin:${PATH} make
Cross-compiling GCC requires that a portion of the target platform's C standard library be available on the host platform. The programmer may choose to compile the full C library, but this choice could be unreliable. The alternative is to use newlib, which is a small C library containing only the most essential components required to compile C source code.
The GNU Autotools packages (i.e. autoconf, automake, and libtool) use the notion of a build platform, a host platform, and a target platform. The build platform is where the compiler is actually compiled. In most cases, build should be left undefined (it will default from host). The host platform is always where the output artifacts from the compiler will be executed whether the output is another compiler or not. The target platform is used when cross-compiling cross compilers, it represents what type of object code the package will produce; otherwise the target platform setting is irrelevant.[3] For example, consider cross-compiling a video game that will run on a Dreamcast. The machine where the game is compiled is the build platform while the Dreamcast is the host platform. The names host and target are relative to the compiler being used and shifted like son and grandson.[4]
Another method popularly used by embedded Linux developers involves the combination of GCC compilers with specialized sandboxes like Scratchbox and Scratchbox 2, or PRoot. These tools create a "chrooted" sandbox where the programmer can build up necessary tools, libc, and libraries without having to set extra paths. Facilities are also provided to "deceive" the runtime so that it "believes" it is actually running on the intended target CPU (such as an ARM architecture); this allows configuration scripts and the like to run without error. Scratchbox runs more slowly by comparison to "non-chrooted" methods, and most tools that are on the host must be moved into Scratchbox to function.
Manx Aztec C cross compilers
[edit]Manx Software Systems, of Shrewsbury, New Jersey, produced C compilers beginning in the 1980s targeted at professional developers for a variety of platforms up to and including IBM PC compatibles and Macs.
Manx's Aztec C programming language was available for a variety of platforms including MS-DOS, Apple II, DOS 3.3 and ProDOS, Commodore 64, Mac 68k[5] and Amiga.
From the 1980s and continuing throughout the 1990s until Manx Software Systems disappeared, the MS-DOS version of Aztec C[6] was offered both as a native mode compiler or as a cross compiler for other platforms with different processors including the Commodore 64[7] and Apple II.[8] Internet distributions still exist for Aztec C including their MS-DOS based cross compilers. They are still in use today.
Manx's Aztec C86, their native mode 8086 MS-DOS compiler, was also a cross compiler. Although it did not compile code for a different processor like their Aztec C65 6502 cross compilers for the Commodore 64 and Apple II, it created binary executables for then-legacy operating systems for the 16-bit 8086 family of processors.
When the IBM PC was first introduced it was available with a choice of operating systems, CP/M-86 and PC DOS being two of them. Aztec C86 was provided with link libraries for generating code for both IBM PC operating systems. Throughout the 1980s later versions of Aztec C86 (3.xx, 4.xx and 5.xx) added support for MS-DOS "transitory" versions 1 and 2[9] and which were less robust than the "baseline" MS-DOS version 3 and later which Aztec C86 targeted until its demise.
Finally, Aztec C86 provided C language developers with the ability to produce ROM-able "HEX" code which could then be transferred using a ROM burner directly to an 8086 based processor. Paravirtualization may be more common today but the practice of creating low-level ROM code was more common per-capita during those years when device driver development was often done by application programmers for individual applications, and new devices amounted to a cottage industry. It was not uncommon for application programmers to interface directly with hardware without support from the manufacturer. This practice was similar to Embedded Systems Development today.
Thomas Fenwick and James Goodnow II were the two principal developers of Aztec-C. Fenwick later became notable as the author of the Microsoft Windows CE kernel or NK ("New Kernel") as it was then called.[10]
Microsoft C cross compilers
[edit]Early history – 1980s
[edit]Microsoft C (MSC) has a shorter history than others[11] dating back to the 1980s. The first Microsoft C Compilers were made by the same company who made Lattice C and were rebranded by Microsoft as their own, until MSC 4 was released, which was the first version that Microsoft produced themselves.[12]
In 1987, many developers started switching to Microsoft C, and many more would follow throughout the development of Microsoft Windows to its present state. Products like Clipper and later Clarion emerged that offered easy database application development by using cross language techniques, allowing part of their programs to be compiled with Microsoft C.
Borland C (California company) was available for purchase years before Microsoft released its first C product.
1987
[edit]C programs had long been linked with modules written in assembly language. Most C compilers (even current compilers) offer an assembly language pass (that can be tweaked for efficiency then linked to the rest of the program after assembling).
Compilers like Aztec-C converted everything to assembly language as a distinct pass and then assembled the code in a distinct pass, and were noted for their very efficient and small code, but by 1987 the optimizer built into Microsoft C was very good, and only "mission critical" parts of a program were usually considered for rewriting. In fact, C language programming had taken over as the "lowest-level" language, with programming becoming a multi-disciplinary growth industry and projects becoming larger, with programmers writing user interfaces and database interfaces in higher-level languages, and a need had emerged for cross language development that continues to this day.
By 1987, with the release of MSC 5.1, Microsoft offered a cross language development environment for MS-DOS. 16-bit binary object code written in assembly language (MASM) and Microsoft's other languages including QuickBASIC, Pascal, and Fortran could be linked together into one program, in a process they called "Mixed Language Programming" and now "InterLanguage Calling".[13] If BASIC was used in this mix, the main program needed to be in BASIC to support the internal runtime system that compiled BASIC required for garbage collection and its other managed operations that simulated a BASIC interpreter like QBasic in MS-DOS.
The calling convention for C code, in particular, was to pass parameters in "reverse order" on the stack and return values on the stack rather than in a processor register. There were other programming rules to make all the languages work together, but this particular rule persisted through the cross language development that continued throughout Windows 16- and 32-bit versions and in the development of programs for OS/2, and which persists to this day. It is known as the Pascal calling convention.
Another type of cross compilation that Microsoft C was used for during this time was in retail applications that require handheld devices like the Symbol Technologies PDT3100 (used to take inventory), which provided a link library targeted at an 8088 based barcode reader. The application was built on the host computer then transferred to the handheld device (via a serial cable) where it was run, similar to what is done today for that same market using Windows Mobile by companies like Motorola, who bought Symbol.
Early 1990s
[edit]Throughout the 1990s and beginning with MSC 6 (their first ANSI C compliant compiler) Microsoft re-focused their C compilers on the emerging Windows market, and also on OS/2 and in the development of GUI programs. Mixed language compatibility remained through MSC 6 on the MS-DOS side, but the API for Microsoft Windows 3.0 and 3.1 was written in MSC 6. MSC 6 was also extended to provide support for 32-bit assemblies and support for the emerging Windows for Workgroups and Windows NT which would form the foundation for Windows XP. A programming practice called a thunk was introduced to allow passing between 16- and 32-bit programs that took advantage of runtime binding (dynamic linking) rather than the static binding that was favoured in monolithic 16-bit MS-DOS applications. Static binding is still favoured by some native code developers but does not generally provide the degree of code reuse required by newer best practices like the Capability Maturity Model (CMM).
MS-DOS support was still provided with the release of Microsoft's first C++ Compiler, MSC 7, which was backwardly compatible with the C programming language and MS-DOS and supported both 16- and 32-bit code generation.
MSC took over where Aztec C86 left off. The market share for C compilers had turned to cross compilers which took advantage of the latest and greatest Windows features, offered C and C++ in a single bundle, and still supported MS-DOS systems that were already a decade old, and the smaller companies that produced compilers like Aztec C could no longer compete and either turned to niche markets like embedded systems or disappeared.
MS-DOS and 16-bit code generation support continued until MSC 8.00c which was bundled with Microsoft C++ and Microsoft Application Studio 1.5, the forerunner of Microsoft Visual Studio which is the cross development environment that Microsoft provide today.
Late 1990s
[edit]MSC 12 was released with Microsoft Visual Studio 6 and no longer provided support for MS-DOS 16-bit binaries, instead providing support for 32-bit console applications, but provided support for Windows 95 and Windows 98 code generation as well as for Windows NT. Link libraries were available for other processors that ran Microsoft Windows; a practice that Microsoft continues to this day.
MSC 13 was released with Visual Studio 2003, and MSC 14 was released with Visual Studio 2005, both of which still produce code for older systems like Windows 95, but which will produce code for several target platforms including the mobile market and the ARM architecture.
.NET and beyond
[edit]In 2001 Microsoft developed the Common Language Runtime (CLR), which formed the core for their .NET Framework compiler in the Visual Studio IDE. This layer on the operating system which is in the API allows the mixing of development languages compiled across platforms that run the Windows operating system.
The .NET Framework runtime and CLR provide a mapping layer to the core routines for the processor and the devices on the target computer. The command-line C compiler in Visual Studio will compile native code for a variety of processors and can be used to build the core routines themselves.
Microsoft .NET applications for target platforms like Windows Mobile on the ARM architecture cross-compile on Windows machines with a variety of processors and Microsoft also offer emulators and remote deployment environments that require very little configuration, unlike the cross compilers in days gone by or on other platforms.
Runtime libraries, such as Mono, provide compatibility for cross-compiled .NET programs to other operating systems, such as Linux.
Libraries like Qt and its predecessors including XVT provide source code level cross development capability with other platforms, while still using Microsoft C to build the Windows versions. Other compilers like MinGW have also become popular in this area since they are more directly compatible with the Unixes that comprise the non-Windows side of software development allowing those developers to target all platforms using a familiar build environment.
Free Pascal
[edit]Free Pascal was developed from the beginning as a cross compiler. The compiler executable (ppcXXX where XXX is a target architecture) is capable of producing executables (or just object files if no internal linker exists, or even just assembly files if no internal assembler exists) for all OS of the same architecture. For example, ppc386 is capable of producing executables for i386-linux, i386-win32, i386-go32v2 (DOS) and all other OSes (see [14]). For compiling to another architecture, however, a cross architecture version of the compiler must be built first. The resulting compiler executable would have additional 'ross' before the target architecture in its name. i.e. if the compiler is built to target x64, then the executable would be ppcrossx64.
To compile for a chosen architecture-OS, the compiler switch (for the compiler driver fpc) -P and -T can be used. This is also done when cross-compiling the compiler itself, but is set via make option CPU_TARGET and OS_TARGET. GNU assembler and linker for the target platform is required if Free Pascal does not yet have internal version of the tools for the target platform.
Clang
[edit]Clang is natively a cross compiler, at build time you can select which architectures you want Clang to be able to target.
Plan 9
[edit]The heterogenous system Plan 9 and its toolchain does not distinguish between cross and native compilation. Makefiles are architecture independent.
See also
[edit]References
[edit]- ^ "4.9 Canadian Crosses". CrossGCC. Archived from the original on October 9, 2004. Retrieved 2012-08-08.
This is called a `Canadian Cross' because at the time a name was needed, Canada had three national parties.
- ^ Ritchie, D. M. (October 1984). "The UNIX System: The Evolution of the UNIX Time-sharing System". AT&T Bell Laboratories Technical Journal. 63 (8): 1577–1593. doi:10.1002/j.1538-7305.1984.tb00054.x.
- ^ "Cross-Compilation (Automake)".
- ^ "Cross compilation".
- ^ "Obsolete Macintosh Computers". Archived from the original on 2008-02-26. Retrieved 2008-03-10.
- ^ Aztec C
- ^ Commodore 64
- ^ Apple II
- ^ MS-DOS Timeline Archived 2008-05-01 at the Wayback Machine
- ^ Inside Windows CE (search for Fenwick)
- ^ Microsoft Language Utility Version History
- ^ History of PC based C-compilers Archived December 15, 2007, at the Wayback Machine
- ^ Which Basic Versions Can CALL C, FORTRAN, Pascal, MASM
- ^ "Free Pascal Supported Platform List". Platform List. Retrieved 2010-06-17.
i386
External links
[edit]- Cross Compilation Tools – reference for configuring GNU cross compilation tools
- Building Cross Toolchains with gcc is a wiki of other GCC cross-compilation references
- Scratchbox is a toolkit for Linux cross-compilation to ARM and x86 targets
- Grand Unified Builder (GUB) for Linux to cross-compile multiple architectures e.g.:Win32/Mac OS/FreeBSD/Linux used by GNU LilyPond
- Crosstool is a helpful toolchain of scripts, which create a Linux cross-compile environment for the desired architecture, including embedded systems
- crosstool-NG is a rewrite of Crosstool and helps building toolchains.
- buildroot is another set of scripts for building a uClibc-based toolchain, usually for embedded systems. It is utilized by OpenWrt.
- ELDK (Embedded Linux Development Kit). Utilized by Das U-Boot.
- T2 SDE is another set of scripts for building whole Linux Systems based on either GNU libC, uClibc or dietlibc for a variety of architectures
- Cross Linux from Scratch Project
- IBM has a very clear structured tutorial about cross-building a GCC toolchain.
- (in French) Cross-compilation avec GCC 4 sous Windows pour Linux - A tutorial to build a cross-GCC toolchain, but from Windows to Linux, a subject rarely developed
Cross compiler
View on GrokipediaFundamentals
Definition and Purpose
A cross compiler is a compiler that executes on one computing platform, referred to as the host, while generating executable code for a distinct platform, known as the target.[4] This distinguishes it from a native compiler, which both runs and produces code for the same platform.[5] The core capability enables developers to build software for diverse architectures without requiring the target hardware during the compilation process. The primary purpose of a cross compiler is to support software development for resource-constrained or specialized environments, such as embedded systems, mobile devices, or remote servers, where running a native compiler directly on the target would be inefficient or impossible due to limited processing power, memory, or absence of a full development toolchain.[6] For instance, developers often use an x86-based host machine to compile code for ARM-based targets, like microcontrollers in IoT devices, avoiding the need to maintain multiple physical development setups.[7] This approach streamlines multi-platform engineering by allowing rapid iteration and testing on powerful host systems before deployment. In terms of workflow, a cross compiler processes source code input on the host through standard compiler phases: lexical analysis to tokenize the code, syntax analysis to build a parse tree, semantic analysis to verify meaning and types, and intermediate code generation or optimization that remains largely platform-agnostic.[5] The key divergence occurs in the code generation phase, where the compiler emits object code, assembly, or binaries tailored to the target's instruction set architecture (ISA), addressing specifics like register allocation, calling conventions, and endianness.[8] Linking integrates target-specific libraries and runtime support, ensuring the output is executable on the intended platform without host dependencies.[9] This target-focused backend requires configuration with details like the target's ABI and sysroot for accurate emulation of the execution environment.Types of Cross Compilers
Cross compilers can be categorized based on the relationships between the build platform (where the compiler is compiled), the host platform (where the compiler runs), and the target platform (for which the compiler generates code). In a simple cross compiler, the build and host platforms are identical, but the target platform differs, allowing the compiler to run on the same system used to build it while producing executables for another architecture.[10] For instance, a developer might use a personal computer (PC) running x86 architecture to compile software for a microcontroller like ARM-based embedded devices. This configuration is common in embedded systems development where the host machine's resources are leveraged to generate code for resource-constrained targets.[10] A more complex variant is the Canadian cross compiler, where the build, host, and target platforms are all distinct, necessitating a multi-stage bootstrapping process. In this setup, a bootstrap compiler on the build platform first creates a cross compiler that runs on the host platform; that host-running compiler then builds the final cross compiler for the target platform.[10] This approach is particularly useful when the build machine is slow or inconvenient compared to the host, such as compiling tools for a remote or specialized system.[11] The term "Canadian cross" originated from an analogy to Canada's political landscape at the time the concept was formalized, when the country had three major national parties, reflecting the three distinct platforms involved. Another rare type is the cross-native compiler, where the build platform differs from the host and target platforms, which are the same, resulting in a native compiler for the target that is built remotely. This distinguishes it from a standard cross compiler by producing a tool that runs natively on the target architecture, often used in scenarios like bootstrapping new systems without local compilation resources.[10] Effective cross compilation relies on integrated build environments, particularly toolchains that include components like Binutils, a collection of utilities providing the assembler (as), linker (ld), and other binary manipulation tools essential for handling target-specific formats and dependencies. These components must be cross-compiled early in the process to enable feature testing and linking for the target architecture, ensuring the overall toolchain supports seamless generation of executables across platforms.Applications and Benefits
In Embedded and Target-Specific Development
Cross compilers play a pivotal role in embedded systems development by allowing developers to compile and build software for resource-constrained microcontrollers, such as AVR and ARM-based devices, directly from more powerful host machines like x86 desktops or servers. This approach eliminates the immediate need for physical target hardware during the initial coding and testing phases, enabling faster iteration and prototyping on platforms with limited processing power and memory. For instance, the GNU Arm Embedded Toolchain supports bare-metal development for Cortex-M processors by providing cross-compilation capabilities from host operating systems including Linux, Windows, and macOS, ensuring compatibility with embedded C and C++ code without requiring the target device. Similarly, Microchip's GCC toolchain for AVR microcontrollers facilitates cross compilation from host environments to generate optimized executables for 8-bit AVR targets, streamlining firmware creation for low-power applications. Target-specific optimizations in cross compilers address the unique challenges of embedded environments, including diverse instruction sets, constrained memory models, and real-time performance requirements. Compilers perform interprocedural analysis to optimize register usage and reduce memory accesses tailored to specific architectures, such as replacing multiple operations with single instructions like PowerPC'sbdnz for loop decrements or adapting to ARM's thumb mode for code density. For memory management, techniques like live-variable analysis allocate frequently accessed variables to registers, minimizing fetches in tight memory budgets, while function inlining eliminates call overhead to balance size and speed— for example, aggressive optimizations can reduce code size by up to 30% in ARM loops without significantly impacting execution time. In real-time contexts, profile-driven optimizations use runtime data to prioritize critical paths, which is essential for generating efficient firmware for IoT devices where timing constraints dictate reliability.
Integration of cross compilers with toolchains enhances embedded development by enabling seamless testing through debuggers and simulators, all without physical hardware. The GNU Debugger (GDB) can be cross-compiled alongside the compiler to run on the host, communicating remotely with a lightweight GDBserver on the target or simulator to inspect and step through code execution. This setup supports simulation of ARM or MIPS-based embedded systems, allowing developers to validate behavior in virtual environments before deployment, such as emulating microcontroller peripherals for early bug detection.
In automotive applications, cross compilation accelerates electronic control unit (ECU) development by enabling virtual ECUs (vECUs) compiled for host platforms like x86, which validate higher-level software layers early without waiting for hardware availability, thereby shortening development cycles by facilitating faster iterations and over-the-air update testing. For example, target-compiled vECUs for ARM-based automotive SoCs allow full-stack simulation of production code, reducing late-stage defects and overall time-to-market in complex E/E architectures. In consumer electronics and IoT, cross compilation has been instrumental in firmware development for devices like the Onion Omega2 microcontroller, where developers use OpenWRT-based toolchains to build MIPS executables on x86 hosts, integrating libraries like libugpio for GPIO handling and enabling rapid prototyping of sensor-reading applications that deploy directly to low-power IoT nodes, cutting development time through host-based compilation and simulation.
In Multi-Platform Software Engineering
Cross compilers play a pivotal role in multi-platform software engineering by enabling developers to compile a single codebase for diverse operating systems such as Windows, Linux, and macOS, as well as architectures like x86 to x64, all from a unified host environment. This portability reduces the need for maintaining separate codebases or toolchains per target, streamlining development workflows and minimizing errors associated with platform-specific adaptations. For example, Clang/LLVM supports this through target triples (e.g.,x86_64-pc-linux-gnu), allowing seamless generation of binaries for multiple environments without rebuilding the entire compiler infrastructure.[12] Similarly, GCC facilitates cross compilation via machine-specific invocations like x86_64-w64-mingw32-gcc, promoting efficient targeting of varied OSes and enhancing overall code reusability.[13]
Integration with continuous integration/continuous deployment (CI/CD) pipelines further amplifies these benefits, automating builds and tests across platforms to ensure reliability and accelerate release cycles. In CI/CD environments, cross compilers allow for parallel execution of platform-specific compilations, such as generating Windows and Linux artifacts from a Linux host, which helps detect portability issues early. Jenkins, for instance, incorporates cross-compilation support in its C/C++ workflows through plugins that manage toolchains and automate multi-target builds, fostering consistent deployment practices in team-based development.[14] This automation is particularly valuable in open-source projects, where contributors from different hosts can verify compatibility without manual reconfiguration.
Despite these advantages, cross compilers introduce challenges in managing dependencies, libraries, and application binary interface (ABI) compatibility across targets, which can result in subtle runtime discrepancies if not addressed. Variations in library paths or versions between hosts and targets often require explicit sysroot specifications or custom linker flags to resolve, complicating build processes. In C++ environments, ABI mismatches—arising from differences in compiler implementations or optimization levels—frequently lead to linking failures or undefined behavior, necessitating standardized interfaces to maintain interoperability. These issues are exacerbated in multi-platform scenarios, where ensuring binary compatibility demands rigorous testing and version pinning.
In practice, cross compilers are indispensable for game development and open-source initiatives requiring broad platform support, such as compiling for consoles, mobile devices, and PCs from a central repository. The Godot Engine, an open-source game framework, leverages cross compilation to build executables for Android, iOS, Windows, and Linux from non-native hosts, enabling developers to maintain a portable codebase while targeting diverse ecosystems. Likewise, Unreal Engine employs cross-compilation tools to produce Linux binaries from Windows development machines, supporting efficient iteration in multi-platform game projects without dedicated per-platform setups.[15][16]
Historical Development
Early Innovations and Timeline
Cross compilers originated in the 1960s and 1970s as essential tools for generating executable code for mainframes and early minicomputers from more powerful host systems, addressing the limitations of resource-constrained targets. Early instances arose in systems programming, such as the initial development of Unix in 1969, where software for the PDP-7 minicomputer was cross-compiled on a GE mainframe due to the PDP-7's inadequate compilation capabilities.[17] This practice highlighted the need for cross-development to bootstrap operating systems and applications on emerging hardware. By the early 1970s, minicomputers like the PDP-11, introduced in 1970, served as hosts for cross compilers targeting smaller devices, marking a pivotal shift toward efficient software production for distributed computing environments.[18] The 1970s saw significant milestones in cross compiler evolution, exemplified by the UCSD Pascal system released in 1977, which employed a portable p-code intermediate representation to enable cross-compilation across diverse architectures, including the PDP-11 and Intel 8080/Z80 processors.[19] A concrete implementation was the 1978 Pascal/P-Code cross compiler developed at Stanford for the LSI-11 minicomputer, demonstrating how p-code facilitated machine-independent code generation for embedded targets.[20] These advancements built on earlier Fortran and assembler-based cross tools used for microcomputer development, often hosted on mainframes or minicomputers to overcome the slow and memory-limited native compilation on 8-bit systems. Entering the 1980s, cross compilers gained prominence with the rise of personal computers, enabling developers to target 8-bit microprocessors from more capable hosts like the PDP-11 or early PCs, which accelerated software creation for consumer electronics and embedded applications. A key event was Intel's release of cross development tools for the iAPX 86 (8086) microprocessor in 1981, integrated into their software ecosystem to support assembly and linking on host systems for the burgeoning x86 architecture.[21] Innovations during this era included the introduction of retargetable compilers, such as R.S. Glanville's 1978 machine-independent code generation algorithm, which allowed back-end adaptations for multiple targets without rewriting front-ends.[22] Concurrently, the University of Utah's 1970s retargetable optimizing compiler for Standard Lisp exemplified early efforts in modular toolchain design, combining compilers, assemblers, and debuggers into cohesive cross-development pipelines.[23] By the transition to the 1990s, cross compilation shifted toward open-source models and standardized frameworks, fostering broader accessibility and portability across platforms, including variants like the Canadian Cross for multi-host builds. This evolution laid the groundwork for integrated ecosystems that emphasized retargetability and reduced vendor lock-in, influencing subsequent toolchain standardization.Canadian Cross and Build Processes
The Canadian Cross is a bootstrapping technique in cross compilation that involves three distinct platforms: the build platform (where the compilation occurs), the host platform (where the resulting compiler runs), and the target platform (for which the compiler generates code), ensuring build ≠ host ≠ target. This method emerged in the 1980s to address challenges in developing compilers for complex or resource-constrained environments, such as OS/2 and embedded Unix systems, where direct compilation on the intended host was impractical due to hardware limitations or lack of native tools. The term "Canadian Cross" originated from a contemporary analogy to Canada's three major political parties at the time, symbolizing the three involved systems.[11] It gained prominence in projects requiring self-hosting compilers on unsupported platforms, including early uses in GCC bootstrapping to produce native compilers for new architectures without relying on the build machine's runtime.[11] The mechanics of a Canadian Cross involve a multi-stage bootstrap process to construct a cross compiler capable of self-hosting on the target platform. This typically unfolds in three primary stages, often visualized as a sequence of cross-compilation passes:- On the build platform (e.g., machine A), compile a cross compiler using the native tools of A; this cross compiler runs on an intermediate host platform (e.g., machine B) and targets the final platform (e.g., machine C). This stage produces an executable that can operate on B but generates code for C.[24]
- Transfer the intermediate cross compiler to the intermediate host platform (B) or build it there if feasible, then use it to compile the final compiler; this final compiler runs natively on the target platform (C) and produces code for C, enabling self-hosting.[24]
- On the target platform (C), use the newly built native compiler to recompile itself, verifying correctness and establishing a fully self-sustaining toolchain independent of the original build and intermediate hosts.[24]
--build=<build-triplet> (identifying the compilation environment, often via config.guess) and --host=<host-triplet> (specifying the runtime platform), allowing detection of cross-compilation mode without assuming native execution.[11] Environment variables like CC_FOR_BUILD direct compilation of build-time utilities on the build platform, while CC points to the cross compiler for host-targeted code; this isolates dependencies and prevents header or library pollution from the build system.[11] Makefiles, generated by configure, incorporate conditional logic for cross environments, such as using --with-sysroot to prefix target-specific paths and resolve libraries via staged installations (e.g., in a temporary $PREFIX/tools directory), ensuring no host contamination during dependency linking.[24] Challenges arise with tests like AC_TRY_RUN, which fail in cross setups since executables cannot run on the build machine, necessitating simulated or deferred validation.[11]
The primary advantage of the Canadian Cross is its ability to enable self-hosting compilers on platforms lacking native development tools, facilitating porting to embedded or legacy systems without physical access to the target hardware during initial bootstrapping.[11] However, it introduces significant complexity, requiring a complete intermediate cross toolchain (including assemblers and libraries) and multiple build passes, which can prolong development and complicate debugging due to layered abstractions.[24]
Key Implementations
GCC Cross Compilation
The GNU Compiler Collection (GCC), first released in 1987 as the GNU C Compiler, was designed from inception as a retargetable compiler suite capable of generating machine code for diverse architectures, including support for cross-compilation to targets differing from the host system.[26] This foundational portability allowed GCC to compile code on one platform for execution on another, addressing the need for developing software in resource-constrained environments without native compilation tools. Cross-compilation is invoked by specifying the target architecture during both the build configuration of GCC itself and runtime compilation commands, such as using the machine-specific executable like arm-none-eabi-gcc for ARM targets.[13] Building a GCC cross-toolchain begins with configuring the compiler source using the --target option in the GNU configure script, which defines the target system via a triplet format (e.g., --target=mips-linux-gnu for MIPS Linux or --target=powerpc-linux-gnu for PowerPC Linux).[27] This step requires prerequisites like a cross-binutils installation tailored to the same target, which provides assemblers, linkers, and other utilities for handling target-specific object formats and binaries. Subsequently, target libraries such as glibc are compiled and installed to supply the C runtime environment, often necessitating kernel headers for the target to ensure compatibility; the full process culminates in running make to compile GCC and install the resulting toolchain in a designated prefix directory.[28] For instance, on a typical Linux host, one might download GCC sources, configure with options like --prefix=/opt/mips-toolchain --target=mips-linux-gnu --enable-languages=c,c++, then build binutils and glibc in sequence before finalizing GCC. GCC's cross-compilation features include support for multiple targets through separate toolchain installations on the same host, enabling developers to switch between architectures via environment variables or PATH configurations without rebuilding the entire suite. The plugin infrastructure, available since GCC 4.5, allows loading dynamic extensions at compile time to insert custom optimization passes, which is particularly useful in cross-compilation for target-specific analyses while maintaining compatibility with out-of-tree modules. Furthermore, GCC integrates natively with Autotools-based build systems, where projects specify --host and --target during configure to automate detection of cross-toolchains, ensuring portable builds across diverse ecosystems.[29] Since its early versions, which offered rudimentary cross-retargeting via back-end ports, GCC's cross-compilation has advanced through iterative enhancements, particularly after 2000 with improvements in optimization pipelines and target back-ends.[26] A key post-2000 milestone was the introduction of Link-Time Optimization (LTO) in GCC 4.5 (released in 2010), which enables interprocedural optimizations across compilation units by deferring them to the linking phase, yielding more efficient cross-compiled binaries through whole-program analysis without requiring source modifications.[30] These developments, stemming from efforts begun in 2005, have solidified GCC's role in producing high-performance code for embedded and multi-platform targets.[31]Clang and LLVM-Based Tools
Clang serves as a frontend for the LLVM compiler infrastructure, with its development initiated in 2007 by Chris Lattner at Apple to provide a high-quality C, C++, and Objective-C parser and code generator integrated with LLVM's backend.[32] This architecture inherently supports cross-compilation, allowing developers to target diverse architectures without rebuilding the compiler itself, primarily through the-target flag that specifies a target triple in the format <arch><sub>-<vendor>-<sys>-<env>, such as armv7a-apple-ios for iOS devices or wasm32-unknown-unknown for WebAssembly.[33][12] The modular separation of Clang's frontend from LLVM's retargetable backend facilitates easy switching between hosts and targets, contrasting with more monolithic designs by enabling independent evolution of parsing and code generation components.[33]
Key cross-compilation features stem from LLVM's extensible backend, which includes dedicated support for architectures like ARM (e.g., Cortex-M for embedded systems) and WebAssembly, allowing Clang to generate optimized machine code or intermediate representations for these targets via simple command-line invocations.[12] For instance, compiling for ARM requires specifying the target triple and providing a sysroot with target-specific headers and libraries, often using flags like --sysroot and -I for includes.[12] Additionally, Clang's static analyzer enhances cross-code verification by supporting Cross Translation Unit (CTU) analysis, which inlines function definitions from separate compilation units to detect issues like null pointer dereferences or buffer overflows across files, making it valuable for ensuring portability in multi-target projects.[34] This analysis can be automated with tools like CodeChecker, which processes compilation databases to perform interprocedural checks without runtime execution.[34]
In practice, Clang integrates seamlessly with build systems like CMake for multi-platform builds, where toolchain files define the target triple, compiler paths, and sysroot to automate cross-compilation workflows across Windows, Linux, and macOS hosts.[12] For mobile development, Clang powers iOS applications through Xcode, targeting ARM-based Apple silicon with triples like arm64-apple-ios, and supports Android via the NDK, enabling C/C++ code compilation to aarch64-linux-android for devices running ARM or x86 architectures.[12] These capabilities allow developers to maintain a single codebase for both platforms, leveraging Clang's driver to handle linking against platform-specific libraries like libc++ for standard library consistency.[12]
Post-2010 advancements have significantly bolstered Clang's suitability for heterogeneous targets, with enhancements to diagnostics providing more precise, context-aware error messages that highlight fix-its for cross-platform portability issues, such as type mismatches in architecture-specific code.[35] Optimization improvements, including better vectorization and loop unrolling in LLVM passes, have optimized performance for diverse hardware like GPUs and accelerators, as seen in initial upstream support for OpenACC directives beginning in 2023 via the Clacc project for parallel heterogeneous computing.[35][36] These developments, driven by ongoing LLVM project contributions, have reduced compilation times and improved code quality for targets ranging from embedded ARM devices to WebAssembly modules in browser environments.[37]
Microsoft C and Commercial Variants
Microsoft's involvement in C cross compilers began in the early 1980s with the release of Microsoft C version 1.0 in 1983, a rebranded and adapted version of Lattice C designed for MS-DOS on the Intel 8086 processor, laying the groundwork for subsequent cross-development tools targeting x86 architectures.[38] By 1986, Microsoft C version 4.0 expanded support for MS-DOS environments, including features that facilitated code generation for embedded systems, though primarily native to 8086 hosts.[39] During the 1990s, Microsoft's cross compilation efforts integrated more deeply with its Visual Studio IDE, particularly for mobile and embedded platforms. The introduction of Windows CE in 1996 brought dedicated support through the Embedded Visual C++ toolkit, allowing cross compilation of native C/C++ code from Windows hosts to ARM and x86 targets in Windows CE devices.[40] By the late 1990s, this evolved with eMbedded Visual C++ 3.0 in 2000, which extended cross compilation capabilities to the Pocket PC platform, supporting development for StrongARM processors and enabling optimized applications for handheld devices running Windows CE-based systems.[41] Visual Studio 6.0, released in 1998, further streamlined this process by incorporating Windows CE project templates and SDK integration for seamless cross builds.[42] In the 2000s, Microsoft shifted toward managed code paradigms with the .NET Framework, introduced in 2002, which facilitated cross-platform code generation through intermediate language (IL) compilation, allowing a single codebase to target multiple architectures via the Common Language Runtime (CLR), including embedded and mobile variants like the .NET Compact Framework for Windows Mobile.[43] This approach reduced the need for traditional native cross compilers in some scenarios by enabling just-in-time or ahead-of-time compilation on diverse targets.[44] In modern iterations, Visual C++ leverages vcpkg, a cross-platform package manager introduced by Microsoft in 2016, to support building and integrating C++ libraries for Windows, Linux, Android, and iOS from a unified Visual Studio environment, with over 70 predefined triplets for configuring target architectures, operating systems, and runtimes.[45] Commercial variants of C cross compilers in this era included Manx Software Systems' Aztec C, which from the mid-1980s to the 1990s provided robust cross compilation for targets like the Amiga (68000 processor) and Z80-based systems from MS-DOS or UNIX hosts, generating efficient assembly code with optimizations for embedded and 8-bit environments.[46] Aztec C's OEM licensing model allowed hardware vendors and developers to embed and redistribute customized versions of the compiler within their development kits, promoting widespread adoption in proprietary embedded projects through site-wide and royalty-based agreements.Other Notable Examples
The Free Pascal Compiler (FPC), initiated in June 1993 by Florian Klaempfl, serves as an open-source cross compiler for Pascal and Object Pascal dialects, compatible with Delphi code.[47] It supports over 20 target architectures, including x86, ARM, MIPS, PowerPC, and embedded platforms like AVR and STM8, enabling development for diverse systems from desktops to microcontrollers.[48] A key feature is smart linking, which selectively includes only referenced code segments in the output binary, reducing executable size and improving performance, particularly beneficial for resource-constrained embedded applications.[49] Plan 9, developed by Bell Labs in the early 1990s as a distributed operating system succeeding Unix, integrates cross-compilation tools natively to support seamless development across heterogeneous hardware.[50] Its C compiler, 8c, targets architectures like the Intel 386 and SPARC, with machine-independent code generation that facilitates cross-compilation without modifications, allowing binaries to run on little-endian MIPS to big-endian processors.[51] This design emphasizes distributed development, where components such as CPU servers, file servers, and terminals interconnect via the 9P protocol, treating resources uniformly to simplify builds in networked environments.[52] Another niche example is the Small Device C Compiler (SDCC), an open-source, retargetable optimizer for ANSI C standards (C89 through C23) primarily targeting Intel MCS51-based microcontrollers like the 8051.[53] SDCC's unique contributions include its integrated suite of assembler, linker, simulator, and debugger tailored for 8-bit embedded systems, along with optimizations for limited memory and code density, such as peephole improvements and support for extended addressing modes in variants like the DS80C400.[54] These features have made it a staple for developing firmware in legacy and low-power IoT devices, outperforming proprietary tools in accessibility for hobbyists and educators. These tools diverge philosophically from mainstream compilers: Free Pascal prioritizes portability and efficiency in high-level languages for broad application development, while SDCC focuses on low-level optimizations for tiny embedded targets; Plan 9's approach, conversely, embeds cross-compilation into a "everything is a file" paradigm, using tools like mk for declarative, file-system-driven builds that enhance distributed collaboration over traditional make-based systems.[50]Modern Practices and Challenges
Integration with Build Systems
Cross compilers integrate seamlessly with modern build systems to enable conditional compilation for specific target platforms, allowing developers to generate executables for diverse architectures from a single host environment. In CMake, this is facilitated through toolchain files that define the cross-compiler, sysroot, and search paths, invoked via the-DCMAKE_TOOLCHAIN_FILE option during configuration.[55] For instance, a toolchain file might set CMAKE_C_COMPILER to a path like /usr/bin/arm-linux-gnueabihf-gcc for ARM targets, while CMAKE_SYSROOT points to the target's root filesystem to ensure headers and libraries are sourced correctly.[55] These files support generators like Ninja for fast parallel builds or traditional Make for broader compatibility, with CMAKE_CROSSCOMPILING set to true to trigger target-specific logic in CMakeLists.txt.[55]
GNU Make handles cross-compilation by overriding variables such as CC and CXX in Makefiles to point to the target toolchain, often combined with conditional directives like ifneq ($(findstring cross,$(TARGET)),) to select build rules based on the target triplet. Ninja, typically as a backend for higher-level systems like CMake, relies on generated build files that embed cross-tool invocations, ensuring efficient dependency resolution without manual path adjustments in most cases.[55] Cross-specification in these systems, akin to CMake's toolchain files, often involves defining target-specific flags in a dedicated file, such as specifying --sysroot for library discovery during linking.
Containerization enhances reproducibility in cross-compilation by encapsulating toolchains within Docker images, isolating the build environment from the host. Docker's multi-platform build feature allows a single docker buildx build command to produce images for multiple architectures, such as linux/amd64 and linux/arm64, using cross-compilation stages in the Dockerfile.[56] For example, a multi-stage Dockerfile might use a base image like golang:alpine on the build platform, then cross-compile with environment variables like GOOS=linux GOARCH=arm64 to target ARM, ensuring consistent outputs across builds.[56] Pre-built cross-toolchain images, such as those from the multiarch/crossbuild repository, provide ready-to-use environments with compilers like GCC for various targets, minimizing setup variability.[56]
Despite these integrations, cross-compilation presents challenges in path resolution and library linking, as the host and target systems often have mismatched filesystems. In CMake, incorrect paths can lead to the build system searching host directories for target libraries, resolved by setting CMAKE_FIND_ROOT_PATH to target-specific directories and modes like CMAKE_FIND_ROOT_PATH_MODE_LIBRARY=ONLY to restrict searches.[55] Similarly, in Autotools, configuration tests like AC_CHECK_LIB may fail if target libraries are absent on the host, requiring manual specification of linker flags via LDFLAGS or a sysroot to avoid linking host artifacts.[57] These issues can result in runtime errors from architecture mismatches, emphasizing the need for verified sysroots during setup.
Best practices for integrating cross compilers with build systems include leveraging environment variables in Autotools to distinguish compilation contexts, such as CC_FOR_TARGET for the target's C compiler (e.g., arm-linux-gcc) and CC_FOR_BUILD for host utilities.[58] During ./configure, options like --host=arm-linux-gnueabihf combined with these variables ensure tools like ranlib are prefixed correctly (e.g., arm-linux-gnueabihf-ranlib), promoting portable and error-free builds.[58] For broader ecosystems, defining a canonical system type via AC_CANONICAL_TARGET in configure.ac aids in conditional logic, while always validating outputs with target emulators like QEMU to catch linking discrepancies early.[58]