What is a compiler toolchain


Cross compilers play an important role, especially in the embedded environment. The target systems are usually too small to support a native development environment. The main reasons for this are economic: Every component that is not required for operation causes unnecessary costs. Those who produce high quantities literally have to count on every tenth of a cent and skimp on material wherever possible.

Individual software packages such as gcc or binutils can be induced with simple means to generate code for a different computer architecture. The pivotal point is the configuration script configureto whom you have to explain what you want before translating. The options are used for this --build, --host and --target.

The former divides configure with what kind of system the translation takes place on; however, the script is often able to figure that out for itself. With --host = the user can specify the computer architecture on which the software should run - i686-pc-linux-gnu stands for a modern PC under Linux. If the compiler is to generate machine code for another system - i.e. to work as a cross compiler - you have to --target = set the target architecture, for example sparc64-sun-solaris2. Then you can as usual make call.

Mutual dependencies

However, that is not the end of it. A complete development environment includes a compiler, assembler and linker (the latter are included in the package binutils included) also debugging tools, the runtime library libc and possibly other libraries along with the associated header files. In Linux, the header files of the kernel for the target machine are also required for compilation. If you want to test the developed software, you also need the translated kernel.

Dependencies between the individual packages make setting up a complete toolchain a tedious task. On the one hand, it is important to adhere to the correct order when translating - some packages even have to be repeated several times with different ones configure- Translate options. On the other hand, the user has to take into account the characteristics of the target platform and possibly install additional patches.

More or less complete recipes for individual platforms can be found on the Internet, for example in the relevant developer forums. However, if you want to get there quickly, you should consider using a pre-made baking mix: crosstool-NG by Yann Morin. Apart from the required source code packages, it contains all the important ingredients for a number of different systems, including proven configurations for Linux on Alpha, ARM, Itanium, Mips, PowerPC, x86 and x86_64 platforms as well as bare metal Systems with ARM or Mips processors. As a runtime library, glibc, µClibc or the comparatively young one eglibc (Embedded Glibc) can be used. A detailed list of the tested toolchains can be found on the project homepage (see box "Online sources"). Further target platforms and operating systems are to follow. Linux, Mac OS X and Windows / Cygwin are suitable as development systems (host).

Whoever wants can crosstool-NG Install like any other software package. However, it can also be used without installation, if you do it before translating ./configure with the option --local and later the program in the same directory with the command ./ct-ng starts.

Toolchains à la carte

Similar to the Linux kernel, the user can use a new configuration ct-ng menuconfig create menu-driven or with ct-ng oldconfig Take over from an existing configuration file. Alternatively, he can use ct-ng call up one of the ready-made configurations. The final command ct-ng build starts the translation process; everything else is automatic. The program downloads the required source code packages from the Internet - unless a local mirror is used - unpacks them, applies the necessary patches, generates the binaries and installs them in the desired directory. Owners of a multi-core computer can speed up the process a bit by using ct-ng build. let several processes work in parallel.

For test purposes, the compilation process can be stopped or continued at certain points by setting the environment variables STOP and RESTART puts. Their values ​​must correspond to the name of one of the translation phases. With ct-ng STOP = binutils about holds ct-ng after translating the binutils at, ct-ng RESTART = binutils skips all previous steps. The list of "breakpoints" depends on the selected configuration and can be opened with ct-ng list-steps ask.

iX links