You have three choices for your cross development toolchain: you may find a ready built toolchain that matches your needs, you can use the one generated by an embedded build tool which is covered in Chapter 6, Selecting a Build System, or you can create one yourself as described later in this chapter.
A pre-built cross toolchain is an attractive option in that you only have to download and install it, but you are limited to the configuration of that particular toolchain and you are dependent on the person or organization you got it from. Most likely, it will be one of these:
- SoC or board vendor. Most vendors offer a Linux toolchain.
- A consortium dedicated to providing system-level support for a given architecture. For example, Linaro, (https://www.linaro.org) have pre-built toolchains for the ARM architecture.
- Third-party Linux tool vendors such as Mentor Graphics, TimeSys, or MontaVista.
- Cross tool packages for your desktop Linux distribution, for example, Debian-based distributions have packages for cross compiling for ARM, MIPS, and PowerPC targets.
- A binary SDK produced by one of the integrated embedded build tools, the Yocto Project has some examples at http://autobuilder.yoctoproject.org/pub/releases/CURRENT/toolchain and there is also the Denx Embedded Linux Development Kit at ftp://ftp.denx.de/pub/eldk/.
- A link from a forum that you can't find any more.
In all of these cases, you have to decide whether the pre-built toolchain on offer meets your requirements. Does it use the C library you prefer? Will the provider give you updates for security fixes and bugs, bearing in mind my comments on support and updates from Chapter 1, Starting Out. If your answer is no to any of these then you should consider creating your own.
Unfortunately, building a toolchain is no easy task. If you truly want to do the whole thing yourself, take a look at Cross Linux From Scratch (http://trac.clfs.org). There, you will find step-by-step instructions on how to create each component.
A simpler alternative is to use crosstool-NG, which encapsulates the process into a set of scripts and has a menu-driven front-end. You still need a fair degree of knowledge, though, just to make the right choices.
It is simpler still to use a build system such as Buildroot or the Yocto Project since they generate a toolchain as part of the build process. This is my preferred solution as I have shown in Chapter 6, Selecting a Build System.
I am going to begin with crosstool-NG because it allows you to see the process of creating the toolchain and to create several different sorts.
Some years ago, Dan Kegel wrote a set of scripts and makefiles for generating cross development toolchains and called it crosstool (kegel.com/crosstool). In 2007, Yann E. Morin used that base to create the next generation of crosstool, crosstool-NG (crosstool-ng.org). Today it is, by far, the most convenient way to create a stand-alone cross toolchain from source.
Before you begin, you will need a working native toolchain and build tools on your host PC. To work with crosstool-NG on an Ubuntu host, you will need to install the packages using the following command:
$ sudo apt-get install automake bison chrpath flex g++ git gperf gawk libexpat1-dev libncurses5-dev libsdl1.2-dev libtool python2.7-dev texinfo
Next, get the current release from the croostool-NG downloads section, http://crosstool-ng.org/download/crosstool-ng. In my examples I have used 1.20.0. Extract it and create the front-end menu system, ct-ng, as shown in the following commands:
$ tar xf crosstool-ng-1.20.0.tar.bz2 $ cd crosstool-ng-1.20.0 $ ./configure --enable-local $ make $ make install
The --enable-local option means that the program will be installed into the current directory, which avoids the need for root permissions as would be required if you were to install it in the default location, /usr/local/bin. Type ./ct-ng from the current directory to launch the crosstool menu.
Crosstool-NG can build many different combinations of toolchains. To make the initial configuration easier, it comes with a set of samples that cover many of the common use-cases. Use ./ct-ng list-samples to generate the list.
As an example, suppose that your target is a BeagleBone Black which has an ARM Cortex A8 core and a VFPv3 floating point unit, and that you want to use a current version of glibc. The closest sample is arm-cortex_a8-linux-gnueabi. You can see the default configuration by prefixing the name with show-:
$ ./ct-ng show-arm-cortex_a8-linux-gnueabi [L..] arm-cortex_a8-linux-gnueabi OS : linux-3.15.4 Companion libs : gmp-5.1.3 mpfr-3.1.2 cloog-ppl-0.18.1 mpc-1.0.2 libelf-0.8.13 binutils : binutils-2.22 C compiler : gcc-4.9.1 (C,C++) C library : glibc-2.19 (threads: nptl) Tools : dmalloc-5.5.2 duma-2_5_15 gdb-7.8 ltrace-0.7.3 strace-4.8
To select this as the target configuration, you would type:
$ ./ct-ng arm-cortex_a8-linux-gnueabi
At this point, you can review the configuration and make changes using the configuration menu command menuconfig:
$ ./ct-ng menuconfig
The menu system is based on the Linux kernel menuconfig and so navigation of the user interface will be familiar to anyone who has configured a kernel. If not, please refer to Chapter 4, Porting and Configuring the Kernel for a description of menuconfig.
There are a few configuration changes that I would recommend you make at this point:
- In Paths and misc options, disable Render the toolchain read-only (
CT_INSTALL_DIR_RO) - In Target options | Floating point, select hardware (FPU) (
CT_ARCH_FLOAT_HW) - In C-library | extra config, add --enable-obsolete-rpc (
CT_LIBC_GLIBC_EXTRA_CONFIG_ARRAY)
The first is necessary if you want to add libraries to the toolchain after it has been installed, which I will describe later in this chapter. The next is to select the optimum floating point implementation for a processor with a hardware floating point unit. The last forces the toolchain to be generated with an obsolete header file, rpc.h, which is still used by a number of packages (note that this is only a problem if you selected glibc). The names in parentheses are the configuration labels stored in the configuration file. When you have made the changes, exit menuconfig, and save the configuration as you do so.
The configuration data is saved into a file named .config. Looking at the file, you will see that the first line of text reads Automatically generated make config: don't edit which is generally good advice, but I recommend that you ignore it in this case. Do you remember from the discussion about toolchain ABIs that ARM has two variants, one which passes floating point parameters in integer registers and one that uses the VFP registers? The float configuration you have just chosen is of the latter type and so the ABI part of the tuple should read eabihf. There is a configuration parameter that does exactly what you want but it is not enabled by default, neither does it appear in the menu, at least not in this version of crosstool. Consequently, you will have to edit .config and add the line shown in bold as follows:
[…] # # arm other options # CT_ARCH_ARM_MODE="arm" CT_ARCH_ARM_MODE_ARM=y # CT_ARCH_ARM_MODE_THUMB is not set # CT_ARCH_ARM_INTERWORKING is not set CT_ARCH_ARM_EABI_FORCE=y CT_ARCH_ARM_EABI=y CT_ARCH_ARM_TUPLE_USE_EABIHF=y [...]
Now you can use crosstool-NG to get, configure, and build the components according to your specification by typing the following command:
$ ./ct-ng build
The build will take about half an hour, after which you will find your toolchain is present in ~/x-tools/arm-cortex_a8-linux-gnueabihf/.