Cross-compiling tool chain Introduction to Building Embedded Linux Systems

1. Preface

Configuring and compiling an appropriate GNU Toolchain is relatively complex and requires fine-grained operations, including the dependencies you need on different repositories, their respective tasks, and a better understanding of the different versions of the repositories, which is a tedious task.

2. Some terms and names that need to be understood before making

1) Build: The compilation system that you use to compile your toolchain.

2) Host: The cross-compiler tool chain runs on the host system.

3) Target: The target system to run for the executable file generated by your cross-compilation toolchain.

In some general non-embedded use, the above three must be the same. But in most embedded development, build and host use the same machine (Developer's workspace). Target is the embedded target board that you develop the application to run.

When we need to use the GNU configuration to build software and systems for a variety of cross-tool chain components, we need to build,host,target by using the GNU config files

System is named, the GNU configuration files are in the following standard format:

1) Cpu-manufacturer-kernel-os (kernel part): This is an optional option, which indicates 3 parts:

①CPU: The chip architecture of the system. (It is customary to add El to the schema name of the small-end variant).

②manufacturer: Specific manufacturer or Development Board family using the above CPU. (This has a small effect on the cross-compiler toolchain, which is often indicated directly as unknown machine type or simply omitting machine descriptions).

③kernel: Mainly used for gnu/linux systems, even sometimes in some cases for brevity and neglect.

④os: The operating system (or ABI) name used on the system. The configuration will be used to describe all kinds of operating systems, including embedded systems that do not run any operating systems, in which case the area is used to indicate the project file format, such as Elf or COFF.

Here are two simple examples:

I386-pc-linux-gnu

Apc-style x86 Linux System

Powerpc-8540-linux-gnu

Afreescale 8540 POWERQUICKIII Linux System

Mips-unknown-linux

A Big-endian MIPS Linux system from an unspecified manufacturer

Mipsel-linux

A Little-endian MIPS Linux system from an unspecified manufacturer

Xscale-unknown-linux

An XScale (formely strongarm) Linux system from an Unspecifiedmanufacturer

In many typical cases, the tools for cross-compiling toolchain are prefixed with the target three combinations. For example, a cross-compilation tool for the Arm,linux system will be named ARM-LINUX-GNU-GCC (where GCC is the executable file name of the GNU compiled series). However, if the connector is for Little-endian MIPS the Linux system will be named MIPSEL-LINUX-LD (LD is the GNU linker's executable file name).

3. Composition requirements for compiling toolchain

1) Linux Kernelheaders

The C library is part of the toolchain, encapsulating many of the APIs available today, and compiling this library requires a subset of the Linux Kenel header files to describe the kernel API.

Theoretically, the Linux kernel version that Toolchain uses for the Linuxkernel headers is consistent with the Linux version used on the target board. But in fact, because the ABI of Linux kernel is seldom changed, it is commonplace to use different versions but similar headers.

Prior to the release of the 2.6 release, C library compilation was based on verbatim copies of the header files in the Linux kernel directory include/asm-architecture and Include/linux. When the linux2.6 is released, it is no longer supported, because the kernel header file contains too much code so it is not suitable for inclusion in the user application space, and the inclusion of C library will easily interrupt the compilation of the user program. The alternative is to use a sanitized Linux kernel header file version, which is appropriate instead of the C library for user code space. Since the linux2.6.23 kernel, the kernel source has been slapped with a slap on the auto make target to build a similar "sanitized" Linux kernelheaders version.

From the kernel source directory, simply execute the following command to change the PPC to your architecture, headers/to the directory where you want to put the sanitized headers installed.

$make ARCH=PPC Headers_check

$make ARCH=PPC install_hdr_path=headers/headers_instal;

2) Binutilspackage

This package contains a lot of tools that are often used to manipulate those binary objects files (binary object file). The two most important tools in this package are the GNU Assembler (AS), Linker (LD). The following table contains the tools you can find in the Binutils package:

3) The C Library

Most of the standard C libraries are often used in the current daily Linux system, the GNU C library. and glibc as a lite version of C library. GLIBC is a portable, efficient C library that supports all relevant standards (ISO c99,posix.1c,posix.1j,posix.1d,unix98, and a single UNIX specification).

GLIBC the entire development project (including links to the development source tree, bug database, and many resources) of the main site:

http://www.gnu.org/software/libc

The list of platforms supported by this library can be queried at the following Web sites:

Http://www.gnu.org/software/libc/ports.html

The library itself can be downloaded to the following Web site:

http://ftp.gnu.org/gnu/glibc

Note: Those packages that do not have ports behind glibc-are not supported for ARM and MIPS, and the ports suffix is appended to the library glibc-that support arm and MIPS, which can be downloaded to by the same path described above. If the project requires smaller RAM, consider using a well-known embedded alternative such as UCLIBC and DIETLIBC.

4) The Threadinglibrary

Threading is a popular modern programming technique that contains several independent, asynchronous tasks but belongs to the same process address space. The Linux kernel provided little support for threads prior to the 2.6 release, and in order to fill such flaws, a number of different thread libraries were developed, the most common of which was the Linuxthreads library. After the Linux2.6 accompanied with a new thread implementation, called the "New POSIX threading Library" (NPTL). NPTL relies on support for threads with the Linux kernel. NPTL is now supported by the Linux Threading Library and is assigned as part of the recent GLIBC release.

We can start using linuxthreads and porting to NPTL because both are compliant with the POSIX standard.

You can test which line libraries is executed during run time by calling the Confstr () function:

#define_XOPEN_SOURCE

#include <unistd.h>

#include <stdio.h>

Intmain (void)

{

Char name[128];

Confstr (_cs_gnu_libpthread_version, name,sizeof (name));

printf ("Pthreads Lib is:%s\n", name);

return 0;

}

5) Componentversions

Before you build the toolchain, you need to select the appropriate version for each part you will use (GCC,GLIBC and binutils). Not all versions of each part and all versions of different parts can be combined to build the right tool chain. You can use the latest version of each part but there is no guarantee that it will work.

In order to choose the right version, we need to test a combination to fit our host and target. You can use the combination that others have passed before, and if not, you need to test it yourself, select the latest stable version for each package, then test it, and if the build fails, use the previous version instead of continuing the test, doing the same thing until the appropriate combination is tested.

Note: In general, the highest version may not be released after a sufficient amount of time, and such a version is not considered a stable version. So for example: glibc2.3 is released, so we'd better choose glibc2.2.5 until glibc2.3.1 starts working.

Here's an example of a test: If the latest version of Binutils is the latest version of 2.1.8,GCC is the latest version of 4.2.2,GLIBC is 2.7. Normally binutils is able to build successfully and we don't need to change it, and then when we build GCC4.2.2, if it fails though all the appropriate configuration identities have been provided. In this case, we need to choose GCC4.2.1 to test and repeat the method until it succeeds. However, it is important to note that sometimes the latest version of the package expects the other package to provide some functionality, so it is sometimes necessary to have a successful build of your previous package and all versions of the next package fail. Backtracking on the package version of the previous successful build. In the example above, we have to go back to glibc2.6.0 and perhaps be suitable for GCC4.1 and binutils2.17, although many recent GCC and binutils can be perfectly combined.

Also, apply patches to some versions to make them correct for our target compilation.

Whenever you find a new version combined with compilation success, test your final toolchain to determine if the toolchain is really working. Because some versions of the combination although can be compiled successfully but the use of the appropriate but still fail. And in some cases, a version combination is found to be available for one processor family, but some other processors in the same processor family are not working.

6) Additionalbuild Requirements

In order to build cross-platform development toolchain, we need a native tool chain function. Many mainstream distributions provide this toolchain as part of their packages. If this attack is not installed in your workspace or you choose not to install it to save space, you need to install it.

4.build main steps involved in content

1) Linux Headers

2) Binary Utilities

3) The Bootstrap compiler

4) The C library

5) The full compiler

One of the things you might notice is that compiler seems to have been built two times. This is normal and necessary because some GCC-supported languages (such as C + +) require GLIBC support. Therefore, a bootstrap compiler is built only used to support C, while the full compiler is built once the C library is valid.

Although we took the Linux headers as the first step, but headers was not used before the C library was set up, all of us could modify this step as long as it was before the C library was set.

Each step involves many iterations of its own. However, these steps remain similar in some behaviors. Many of the tool chain build steps include several behaviors:

① Unpacking Package

② developing configuration packages for cross-platform

③build Bag

④ installation Package

Some tool chains builds slightly different from the above sequence. For example: The Linux headers does not require us to build or install Thekernel. Because the compiler has uninstalled the settings of the bootstrap compiler, the full compiler setting does not need to be required to uninstall the GCC package again.

5. Working Space Settings

1) The tool chain will be built in the ${prjroot}/tools directory based on the early workspace directory hierarchy recommendations. After that we need to define some additional environment variables. This makes the build process much more convenient based on the environment variables that have been defined. Here's a new Develdaq script for setting up new environment variables:

Exportproject=daq-module

Exportprjroot=/home/gby/bels/control-project/${project}

Export Target=powerpc-unknown-linux or Arm-linux

Exporthost=i686-cross-linux-gnu

Exportprefix=${prjroot}/tools

Exporttarget_prefix=${prefix}/${target}

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

Cd$prjroot

Project variable: is the project name, can be written casually

Prjroot variable: Absolute path to this project

Target variable: Defines the architecture of the target platform to which your toolchain will be compiled.

Host variable: Defines the host platform architecture that the tool chain runs on.

Prefix variable: Provides a component configuration script that indicates the directory where you want to install the target tool.

Target_prefix variable: Used for target dependent header file and library installation.

Path variable: In order to use the newly installed tool, we need to modify the path variable to indicate the directory to which the binaries will be installed.

6. Resources

Before making a tool chain of time, let's take a look at some of the resources you might find useful when you encounter problems in your production process.

1) Most importantly, each package has its own documentation. Inside GCC, we can find a FAQ file and an install directory containing instructions on how to configure and install GCC. These contain a large number of instructions for compiling configuration options. Similarly, the GLIBC package also contains FAQs and install files. The Install file covers the compilation with the magenta option and the installation process, and it provides recommendations for using the Build tool version.

2) In addition, we may want to try to use a generic search engine like Google to find records of similar problems that other developers have encountered and resolved. Typically, this is a very effective way to solve the problem of building with the GNU Toolchain.

3) A very useful resource is the cross-compiled Linux from Scratch (CLFS) (http://trac.cross-lfs.org) has been used in some examples of component combination version of the tool chain build already has a lot of is provided in this resource.

The CLFS:CLFS project provides guidance for you to build your own custom Linux system all by using raw materials. There are several advantages to this:

Teach people how to build a cross compiler

Teach people how to use the Multilib system

Teach people how the Linux system works inside

Build Clfs to produce a very compact Linux system

Build Clfs on many Unix-style operating systems

Clfs is very flexible.

Clfs provides additional security

Cross-compiling tool chain Introduction to Building Embedded Linux Systems