Build a cross-compilation tool chain

Build a cross-compilation tool chain
Part from building embedded Linux systems

By Karim yaghmour

Liu Jianwen translated and organized (http://blog.csdn.net/keminlau

)

Key: Cross-compiled embedded Linux C library glibc

Buildroot automatically builds a cross-compilation tool chain

For a long time in the past, building a set of cross-compilation tool chains was a nightmare for embedded developers because they had to manually track various source code packages (and update packages) dependencies between them. Buildroot, and the fact that gadgets released with the famous mini C library uclibc change.

Complicated

Processing and building an appropriate GNU toolchain is a complex and delicate operation that requires a good understanding of the dependencies between the different software packages and their respective roles. this knowledge is required, because the GNU toolchain components are developed and released independently from one another.

 

Buildroot is like a Linux kernel build system

Similar software build system based on GNU make. However, buildroot only contains makefiles and some Patches required for building. Without the source code of the software to be built, the source code must be dynamically downloaded from the Internet. Buildroot is mainly used to build a [cross-compilation tool chain using uclibc

] And the root file system.

What is the cross-compilation tool chain using uclibc?

 

First, you must understand what is the compilation tool chain. The compilation toolchain can be simply understood as a compilation toolset, including the compiler, assembler, linker, and C standard library. The compiler is responsible for converting the source code to a binary machine code (or assembly code), such as GCC. The assembler and linker are responsible for the construction of the executable file, such as binutils; the C standard library is a general machine code library for the linker, such as glibc. From the perspective of the role involved in compiling and building tasks, the first three are appliances and operations, and the last is data materials in database C ].

Next, let's understand what cross-compilation is. The host and target use different CPU Systems, which are compiled on the host to generate the machine code of the target machine. The difference between the cross-compilation toolchain and the local compilation toolchain is: first, the cross-compilation toolchain [compilation appliance] has the function of generating the machine code of the target machine; second, the C library of the tool chain for cross-compilation is the machine code library of the target machine.

The final understanding of what is [using uclibc's cross-compilation toolchain] becomes obvious.

This step raises several issues. First, what does the [compiler] need to do with cross-compilation? Second, how to generate the machine code C library of the target machine? Third, what is the difference between uclibc and glibc?

 

Use buildroot

• Create your own onboard support)
• Offline Construction
• Out-of-tree construction
• Environment Variable
• Customization of the root file system of the target machine
• Busybox Customization
• Uclibc Customization
• Create multiple projects based on a single buildroot source code tree
• Use uclicb tool chain outside buildroot
• Download location of source code package
• Use external tool chain
• Extended buildroot (tool software)

For more information, see the buildroot documentation.

.

Build a cross-compilation tool chain manually

Now that buildroot is available, is it necessary to learn how to build a tool chain? The answer is of course necessary. We do not recommend that we reinvent the wheel, but if we don't invent it ourselves, we never know how the wheel came about. From the perspective of occupation, it should be said that it is not recommended to re-invent external things.

[Embedded Linux development

] The first step is to build a cross-compilation tool chain (which can compile and run the kernel and applications on the Target Platform), and the first step of [embedded Linux development, there is already a tool chain for generating this cross-compilation [Local tool chain

] (Native toolchain); the second step is to organize the working directory of the project.

The local tool chain is usually installed with the release version. If you do not choose to install it, or are accidentally damaged, you can obtain the installation package from the release CD or online for important installation.

Working directory

In the process of developing or customizing various software for your embedded system, you need to use a lot of source code packages and tool sets. Create a clear and easy-to-understand directory structure for these source code packages, toolsets, and other [project-related components]-Project workspace is the first step of work. The following table shows an example. You can adjust it as needed and adjust it intuitively. In addition, separating the code you write from the source code downloaded from the internet can not only reduce the confusion of source code ownership, but also clarify authorization issues.

Table 4-1. Suggested project directory Layout

Directory	Content
Bootldr	Different Versions of bootloader built for Embedded Systems
Build-Tools	Store software packages for building a cross-platform development tool chain
Debug	Debugging tools and related software packages
Doc	Embedded System project documents
Images	Stores the bootloader image, kernel image, and root file system image to be used.
Kernel	Different versions of the kernel built for the Embedded System
Project	The project code you wrote
Rootfs	Stores the root file system when the embedded system kernel is running.
Sysapps	System Tools of different versions built for Embedded Systems
TMP	Temporary Files
Tools	Complete cross-platform development tool chain and C library

 

The preceding directories are subordinate to the subdirectories in your project workspace (of course, these directories also contain subdirectories), and the location of the project workspace is determined by you. However, I recommend that you do not use a system-wide directory, such as/usr or/usr/local. You can use directories in/home or/home, which can be shared to all users in the user group. If you must use a global directory, you can use the/OPT directory.

Below is ~ /Control-project directory:

$ LS-L ~ /Control-Project

Total 4

Drwxr-XR-x 13 Karim 1024 Mar 28 control-Module

Drwxr-XR-x 13 Karim 1024 Mar 28 DAQ-Module

Drwxr-XR-x 13 Karim 1024 Mar 28 sysmgnt-Module

Drwxr-XR-x 13 Karim 1024 Mar 28 user-interface

In particular, there are four embedded projects, each of which has a working directory, and each working directory has a sub-directory with different functions in the table above, such:

$ LS-L ~ /Control-Project/DAQ-Module

Total 11

Drwxr-XR-x 2 Karim 1024 Mar 28 bootldr

Drwxr-XR-x 2 Karim 1024 Mar 28 build-Tools

Drwxr-XR-x 2 Karim 1024 Mar 28 debug

Drwxr-XR-x 2 Karim 1024 Mar 28 Doc

Drwxr-XR-x 2 Karim 1024 Mar 28 images

Drwxr-XR-x 2 Karim 1024 Mar 28 Kernel

Drwxr-XR-x 2 Karim 1024 Mar 28 project

Drwxr-XR-x 2 Karim 1024 Mar 28 rootfs

Drwxr-XR-x 2 Karim 1024 Mar 28 sysapps

Drwxr-XR-x 2 Karim 1024 Mar 28 TMP

Drwxr-XR-x 2 Karim 1024 Mar 28 tools

 

Because some build tools require path information, you can write a short script to complete this task. For example, the following is the script of the DAQ-Module Project develdaq:

Export project = DAQ-Module

Export prjroot =/home/Karim/control-Project/$ {project}

CD $ prjroot

Run it: $. develdaq

Build a toolchain

1. Determine the target name
2. Determine available kernel/GCC/glibc/binutils version combinations
3. Confirm tool directory
4. Prepare the kernel header file
5. Compile binutils
6. Compile the minimal Bootstrap gcc
7. Compile glibc
8. Compile the full-featured gcc

Determine the target name

Target is not the name of the toolchain, but the nature and type of the toolchain. It determines the platform machine code that the toolchain outputs. The definition of target is irrelevant to the local host. It is only related to the target machine. It is defined by the combination of the hardware platform (processor system) and software platform (operating system) of the target machine.

The following are four common targets:

• Arm-Linux: Support for ARM processors such as armv4, armv5t, and so on.
• MIPs-Linux: support for various MIPS core such as r3000, r4000, and so on.
• PPC-Linux: Linux/PowerPC combination with support for various PPC chips.
• The m68k-linux: This targets Linux running on the Motorola 68 K processor.

Complete list at: http://www.gnu.org

Determine available kernel/GCC/glibc/binutils version combinations

This is the most troublesome step to build a tool chain. The installation documentation and email list are the places for obtaining information. The following is a combination of known versions available for ARM-Linux:

• ARM/kernel 2.6/GCC 2.95.1, GCC 3.3/binutils 2.10.x or
• ARM/kernel 2.4/GCC 2.95.1/binutils 2.9.5

Are there any update packages available?

After confirming the version number, make sure that the kernel/GCC/glibc/binutils version has an update package.

Confirm tool directory

As defined in the previous working directory layout, the toolchain will compile the build in $ {prjroot}/build-tools and install it to {prjroot}/tools. To facilitate compilation, we define some environment variables and output them. The following is the content of the script develdaq:

Export project = projectxx

Export prjroot =/home/nakeman/$ {project}

Export target = i386-linux

Export prefix =$ {prjroot}/tools

Export target_prefix =$ {prefix}/$ {target}

Export path =$ {prefix}/bin :$ {path}

CD $ prjroot

 

Target: Target name

Prefix: prefix is the prefix with insufficient semantics. It refers to the path prefix. By default, it refers to the path prefix of the [installation directory of toolchain. For example, the prefix of the local tool chain is generally/usr, which means that you can find GCC in bindir = $ prefix/bin and find the header file in includedir = $ prefix/include. To avoid confusion with the local tool chain, the cross tool chain uses non-/usr as the prefix.

An issue with installing tool chain to/usr/local

 

Some people prefer to set prefix to/usr/local. this results in the tools and libraries being installed within the/usr/local directory where they can be accessed by any user. I find this approach not to be useful for most situations, however, because even projects using the same target architecture may require different toolchain deployments.

 

Build a tool chain for the entire development team

 

If you need to set up a toolchain for an entire development team, instead of sharing tools and Libraries via the/usr/local directory, I suggest that a developer builds the toolchain within an entry shared by all project members in the/home directory, as I said earlier. in a case in which no entry in the/home directory is shared among group members, A developer may build the toolchain within an entry in her workstation's/OPT directory and then share her resulting $ {prjroot}/tools directory with her colleagues. this may be done using any of the traditional sharing mechanic ISMs available, such as NFS, or using a tar-gzipped archive available on an FTP server. each developer using the package will have to place it in a filesystem hierarchy identical to the one used to build the toolchain for the tools to operate adequately. in a case in which the toolchain was built within the/OPT directory, this means placing the toolchain in the/OPT directory.

Environment variables can also be defined in the. bashrc file, so that when you log out or change the console, you do not need to always export these variables.

With the above preparations, you can now build a tool chain.

Compile binutils

1. Download source package (ftp://ftp.gnu.org/gnu/binutils/) and unpack:

$ CD $ prjroot/build-tools/src

$ Tar-xzf binutils-2.10.1.tar.gz

In addition, if there is an update package, it is best to update it.

2. Configure:

$./Configure -- target = $ target -- prefix = $ prefix

The configuration script usually checks the compilation environment, such as some resources of the host, and then generates the makefile required for compilation according to options (such as the target here and the installation location prefix.

3. Compile:

$ Make

4. installation:

$ Make install

Composition and usage of binutils

Utility	Use
As	GNU Assembler
LD	The GNU linker
Gasp	GNU assembler Preprocessor
Ar	Generate, modify, and unbind an archive file
Nm	List the symbols and corresponding addresses of the target file
Objcopy	Convert a target file of a certain format into a target file of another format
Objdump	Displays the content of the target file.
Ranlib	Creates an index for an archive file and stores the index in the archive file.
Readelf	Displays information about the target file in ELF format.
Size	Lists the size of each section of the target file and the size of the target file.
Strings	Print the string that can be printed in the target file. The default length is 4.
Strip	Removes all symbolic information from the target file.
C ++ filt	C ++ and Java have a type of overload function. The used overload function will finally be compiled and converted into the Assembly number. c ++ filt implements this reverse conversion, obtain the function name based on the number.
Addr2line	Convert the address you are looking for into a file and a line number, and use the debug information.

 

Prepare the kernel header file

The first step to compile GCC is to prepare the kernel header file (Kemin: It sounds strange. Compile GCC with GCC, And the compiler itself is also a program. The key is to understand what is needed to compile a compilation ), cross-Compilation of a toolchain requires a kernel header file.

1. Download and unpack the package to $ {prjroot}/kernel;

2. If an update package exists, update it;

3. Change the arch attribute of the kernel by changing the arch variable in makefie at the top of the source code tree;

4. Configure the kernel:

Make menuconfig

Configure two options: System and processor type, and select a system consistent with the tools you're building.

Exit and save the settings. Check include/Linux/version in the kernel directory. H and include/Linux/Autoconf. h file is generated, which is used to compile glibc, version. H and Autoconf. the existence of the H file also indicates that you have generated the correct header file.

5. Copy

$ Mkdir-p $ {target_prefix}/include

$ CP-r include/Linux/$ {target_prefix}/include

$ CP-r include/asm-i386/$ {target_prefix}/include/ASM

$ CP-r include/ASM-generic/$ {target_prefix}/include

Note: unless your toolchain changes the system or processor type, the Kernel configuration is one-time.

Compile the minimal Bootstrap gcc

We first compile a minimal cross-C compiler, then use it to compile glibc on the target platform, and finally compile the fully functional GCC. In this process, the compiling condition of the former depends on the latter. For example, to compile the C ++ compiler, glibc is required, which is a bit like a computer startup.

1. Download and unpack the package. If necessary, update the package:

$ CD $ {prjroot}/build-Tools

$ Tar xvzf gcc-2.95.3.tar.gz

2. Con? Gure:

$ CD build-boot-gcc

$ ../Gcc-2.95.3/configure -- target = $ target -- prefix =$ {prefix }/

> -- Without-headers -- With-newlib -- enable-languages ages = C

In addition to the target and prefix options, three configuration options are different from those for compiling binuilts:

• -- Without-headers: because this is a cross compiler, the system library of the target machine has not been compiled, and glibc has not yet compiled;
• -- With-newlib: This option only means that no library is specified for the compilation to pass smoothly, because glibc has not been compiled yet;
• -- Enable-languages ages = C: This option specifies that the smallest GCC uses the C language.

3. Build:

$ Make

4. Install:

$ Make install

Compile glibc

People familiar with glibc should know that glibc is far more than just a simple general-language code base, which is a modern operating system code base. Besides implementing the Standard C library (libc, it also encapsulates the operating system functional interfaces (POSIX standard), network interfaces, and thread operation interfaces. Most applications use the operating system functions through glibc (link glibc code. In addition, to distinguish glibc from the kernel C library, kernel development does not require glibc, and there is a small C library implementation in the kernel.

1. Download (ftp.gnu.org/gnu/glibc) and unpack:

$ CD $ {prjroot}/build-Tools

$ Tar xvzf glibc-2.2.3.tar.gz

For various reasons, glibc is split into glibc core and added-ons for release. When we configure glibc, if we enable add-ons, this add-ons must be ready (download and release the package in the appropriate location ). Linux threads add-on is generally required for embedded systems.

$ Tar-xvzf glibc-linuxthreads-2.2.3.tar.gz -- directory = glibc-2.2.3

2. Con? Gure:

$ CD build-glibc

$ Cc = $ target-Linux-GCC ../glibc-2.2.3/configure -- Host = $ target/

> -- Prefix = "/usr" -- enable-add-ons = linuxthreads/

> -- With-headers =$ {target_prefix}/include

• Cc: Unlike the previous configuration, the CC variable is modified before glibc is compiled because glibc is compiled to the target machine, therefore, use the compiled $ target-Linux-GCC for cross-compilation.
• -- Host: the configuration item uses -- Host instead of -- target. This database runs on the target machine, not the local machine.
• -- Prefix: this is also the location where glibc is installed on the target machine, rather than the local machine. This cross-compiled code library is not installed locally. This value is used to provide the compiler with a hard-coded installation location of glibc into glibc, And then we modify the installation location during local compilation and installation (see the following installation step ), you only need to copy the generated files to the target machine.
• -- Enable-add-ons: For details, see the configuration document;
• -- With-headers: Glibc depends on the header file of the kernel. If this option is not provided, the header file of the Local Kernel is first compiled with/usr/include, this is inconsistent with the glibc of the compilation target machine.

Some other configuration options may be used:

• -- Disable-profile/-- disable-shared: by default, three sets of library files are generated: Shared Library, static library, and profiling information. If your target machine does not have many applications, you can choose to generate only static databases.
• -- Enable-static-NSS: omitted;
• -- Without-FP: omitted.

3. Build:

$ Make

Note: Due to the large size of glibc, compilation is lengthy and time-consuming. If an error occurs during the compilation process, use make clean to clear the intermediate results before making.

4. Install:

$ Make install_root =$ {target_prefix} prefix = "" Install

As mentioned above, this glibc is installed for the local application for execution. The installation location is specific. Note that the variable prefix is cleared first.

5. The last step is to modify the libc. So file.

Set
Group (/lib/libc. so.6/lib/libc_nonshared.a)

Change

Group (libc. so.6 libc_nonshared.a)

In this way, the connector LD will be in libc. find the library he needs in the directory where so is located, because the/lib directory of your machine may have installed a library with the same name. This is the library for compiling local applications, instead of the library used for cross-compilation.

Compile the full-featured gcc

We only support C when creating boot-GCC. Here, we need to build a full set of compilers to support C and C ++.

$ CD $ prjroot/build-tools/build-gcc

$ ../Gcc-2.95.3/configure -- target = $ target -- prefix = $ prefix -- enable-languages ages = C, C ++

$ Make all

$ Make install

Reference

• How to build a cross-compiling environment for Linux Embedded Development (2.4 kernel): http://www.sudu.cn/info/html/edu/20070101/294486.html
• Original: http://blog.csdn.net/keminlau/archive/2009/12/05/4945951.aspx
• The GNU toolchain for ARM target howto In the ARM architecture
• Linux for PowerPC embedded systems howto In the PowerPC architecture
• The Scott Howard crossgcc FAQ is available at http://www.sthoward.com/CrossGCC.
• The bill gatliff crossgcc FAQ is available at http://crossgcc.billgatliff.com /.
• Crosgcc mailing list hosted by Red Hat at http://sources.redhat.com/ml/crossgcc.