What is linux cross compilation

In Linux, cross-compilation refers to generating executable code on one platform on another platform, that is, the platform for compiling the source code and the platform for executing the compiled program of the source code are two different platforms. Reasons for using cross-compilation: 1. The target system does not have the ability to compile natively on it; 2. The platform capable of compiling source code is different from the target platform.

#The operating environment of this tutorial: linux5.9.8 system, Dell G3 computer.

Cross-compilation

The so-called "cross-compile (Cross_Compile)" refers to the platform for compiling the source code and the execution of the program after the source code is compiled. The platforms are two different platforms. For example, under the Intel x86 architecture/Linux (Ubuntu) platform, the executable file generated using the cross-compilation tool chain runs under the ARM architecture/Linux.

Simply put, it is to generate executable code on one platform on another platform. The same architecture can run different operating systems; similarly, the same operating system can also run on different architectures.

Cross-compilation is relatively complicated, and the following issues must be considered:

• CPU architecture: such as ARM, x86, MIPS, etc.;

• Endianness: big-endian and little-endian;

• Support for floating point numbers;

• Application Binary Interface (ABI);

Why use cross-compilation? There are two main reasons:

• The target system for cross-compilation generally has small memory, poor or even no display equipment, and there is no ability to compile locally on it;

• The CPU architecture or operating system of the platform capable of compiling source code is different from the target platform;

The cross-compilation tool chain is necessary for cross-compilation. It is an indispensable tool and a skill that embedded developers must master.

Why is it difficult to cross-compile?

Portable native compilation is difficult.

Most programs are developed on x86 hardware and compiled natively. Cross-compiling can encounter two types of problems: problems with the program itself and problems with the build system.

The first category of issues affects all non-x86 targets, including native and cross-builds. Most programs make assumptions about the type of machine they are running on, which must match the relevant platform, otherwise the program will not run. Common assumptions include:

• Word size - copying pointer to int may lose data on 64-bit platforms, determine malloc size by multiplying by 4 instead of sizeof(long) not good. Integer overflow leads to minor security vulnerabilities, ala "if (x y

• Endianness - Different systems store binary data internally in different ways, and reading int or float data from disk or the network may require conversion.

• Alignment - Some platforms (such as arm) can only read or write integers from addresses that are an even multiple of 4 bytes, otherwise a segfault will occur. Processing of any aligned, unaligned data is slower, and the compiler usually fills in the structure alignment variables. Treating structures as blocks of data that can be sent to disk or over the network requires additional work to ensure a consistent representation.

• Default signature - "char" data type, defaults to signed or unsigned, varies from platform to platform (from compiler to compiler), leading to some very surprising bugs . The simple workaround is to provide a compiler argument such as "-funsigned-char" that forces the default to a known value.

• NOMMU - If the target platform does not have a memory management unit, a few things need to be changed. Requires vfork(), not fork(), only certain types of mmap() work (shared or read-only, but not copy-on-write), the stack does not grow dynamically.

Most packages aim to be portable when compiled natively and will at least accept patches fixing any of the above issues (except NOMMU issues) submitted to the appropriate development mailing list.

Then cross compilation.

In addition to the issues with native compilation, cross-compiling has its own set of issues:

• Configuration Problem - Packages that have a separate configuration step (the "./configure" part of the standard configure/make/make install), which typically tests things like endianness or page size, are portable when compiled natively. When cross-compiling, these values ​​differ between the host system and the target system, and running the test on the host system gives incorrect answers. When the target does not have the software package or the version is incompatible, the configuration detects whether there is software package support on the host.

• HOSTCC vs TARGETCC - The build process requires compilation to run on the host system, as configured above for testing, or a program that generates code (such as a C program that creates a .h file, #included during the main build) . Replace the host compiler with the target compiler, breaking the runtime library during the build process. Such a library requires access to the host and target compilers and needs to be specified when to use it.

• Toolchain leakage - An improperly configured cross-compilation toolchain leaks some of the contents of the host system into the compiled program, causing failures that are often easy to detect, but difficult to diagnose and correct. . The toolchain may #include the wrong header files, or search for the wrong library paths when linking. Shared libraries often depend on other shared libraries, potentially sneaking in unexpected link-time references to the host system.

• Libraries - Dynamically linked programs must access the appropriate shared libraries at compile time. The shared library of the target system needs to be added to the cross-compilation tool chain so that the program can link to it.

• Testing - On native builds, the development system provides a convenient testing environment. When cross-compiling, confirming that the "hello world" build was successful may require configuring (at least) the bootloader, kernel, root filesystem, and shared libraries.

• Footnote 1: The most significant difference between computer types is the processor that executes the program, other differences include libraries ABI (such as glibc vs. uClibc), machines with configurable endianness (arm vs. armeb), or machines with different modes that can run 32-bit and 64-bit code (such as x86-64 on x86).

• Footnote 2: When building a compiler, the third type is called a "Canadian cross", a cross-compiler that does not run on the host system. Canadian Cross-Build a compiler that runs on one target platform and generates code on another target machine. First create a temporary cross-compiler from the host to the first target and as the second target build another cross-compiler to build such an external compiler. The target of the first cross-compiler becomes the host machine on which the new compiler will run, and the second target is the platform on which the new compiler will generate output. This technique is often used to cross-compile a new native compiler for the target platform.

• Footnote 3: Modern desktop systems are fast enough that emulating targets compiled natively under the emulator is actually a viable strategy. Much slower than cross-compiling, requires finding or generating a native build environment for the target (a cross-compiler must be set up anyway), may crash due to differences between the emulator and the real hardware to be deployed.

• Footnote 4: Cross-compilation toolchains tend to prefix the names of their utilities, ala "armv5l-linux-gcc". If simply called "gcc", the host and native compilers cannot be in $PATH at the same time.

Related recommendations: "Linux Video Tutorial"

The above is the detailed content of What is linux cross compilation. For more information, please follow other related articles on the PHP Chinese website!