To get an idea of what is in a typical toolchain, I want to examine the crosstool-NG toolchain you have just created.
The toolchain is in the directory ~/x-tools/arm-cortex_a8-linux-gnueabihf/bin. In there you will find the cross compiler, arm-cortex_a8-linux-gnueabihf-gcc. To make use of it, you need to add the directory to your path using the following command:
$ PATH=~/x-tools/arm-cortex_a8-linux-gnueabihf/bin:$PATH
Now you can take a simple hello world program that looks like this:
#include <stdio.h>
#include <stdlib.h>
int main (int argc, char *argv[])
{
printf ("Hello, world!
");
return 0;
}And compile it like this:
$ arm-cortex_a8-linux-gnueabihf-gcc helloworld.c -o helloworld
You can confirm that it has been cross compiled by using the file command to print the type of the file:
$ file helloworld helloworld: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 3.15.4, not stripped
Imagine that you have just received a toolchain, and that you would like to know more about how it was configured. You can find out a lot by querying gcc. For example, to find the version, you use --version:
$ arm-cortex_a8-linux-gnueabi-gcc --version arm-cortex_a8-linux-gnueabi-gcc (crosstool-NG 1.20.0) 4.9.1 Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
To find how it was configured, use -v:
$ arm-cortex_a8-linux-gnueabi-gcc -v Using built-in specs. COLLECT_GCC=arm-cortex_a8-linux-gnueabihf-gcc COLLECT_LTO_WRAPPER=/home/chris/x-tools/arm-cortex_a8-linux-gnueabihf/libexec/gcc/arm-cortex_a8-linux-gnueabihf/4.9.1/lto-wrapper Target: arm-cortex_a8-linux-gnueabihf Configured with: /home/chris/hd/home/chris/build/MELP/build/crosstool-ng-1.20.0/.build/src/gcc-4.9.1/configure --build=x86_64-build_unknown-linux-gnu --host=x86_64-build_unknown-linux-gnu --target=arm-cortex_a8-linux-gnueabihf --prefix=/home/chris/x-tools/arm-cortex_a8-linux-gnueabihf --with-sysroot=/home/chris/x-tools/arm-cortex_a8-linux-gnueabihf/arm-cortex_a8-linux-gnueabihf/sysroot --enable-languages=c,c++ --with-arch=armv7-a --with-cpu=cortex-a8 --with-tune=cortex-a8 --with-float=hard --with-pkgversion='crosstool-NG 1.20.0' --enable-__cxa_atexit --disable-libmudflap --disable-libgomp --disable-libssp --disable-libquadmath --disable-libquadmath-support --disable-libsanitizer --with-gmp=/home/chris/hd/home/chris/build/MELP/build/crosstool-ng-1.20.0/.build/arm-cortex_a8-linux-gnueabihf/buildtools --with-mpfr=/home/chris/hd/home/chris/build/MELP/build/crosstool-ng-1.20.0/.build/arm-cortex_a8-linux-gnueabihf/buildtools --with-mpc=/home/chris/hd/home/chris/build/MELP/build/crosstool-ng-1.20.0/.build/arm-cortex_a8-linux-gnueabihf/buildtools --with-isl=/home/chris/hd/home/chris/build/MELP/build/crosstool-ng-1.20.0/.build/arm-cortex_a8-linux-gnueabihf/buildtools --with-cloog=/home/chris/hd/home/chris/build/MELP/build/crosstool-ng-1.20.0/.build/arm-cortex_a8-linux-gnueabihf/buildtools --with-libelf=/home/chris/hd/home/chris/build/MELP/build/crosstool-ng-1.20.0/.build/arm-cortex_a8-linux-gnueabihf/buildtools --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --enable-threads=posix --enable-target-optspace --enable-plugin --enable-gold --disable-nls --disable-multilib --with-local-prefix=/home/chris/x-tools/arm-cortex_a8-linux-gnueabihf/arm-cortex_a8-linux-gnueabihf/sysroot --enable-c99 --enable-long-long Thread model: posix gcc version 4.9.1 (crosstool-NG 1.20.0)
There is a lot of output there but the interesting things to note are:
--with-sysroot=/home/chris/x-tools/arm-cortex_a8-linux-gnueabihf/arm-cortex_a8-linux-gnueabihf/sysroot: This is the default sysroot directory, see the following section for an explanation--enable-languages=c,c++: Using this we have both C and C++ languages enabled--with-arch=armv7-a: The code is generated using the ARM v7a instruction set--with-cpu=cortex-a8 and --with-tune=cortex-a8: The the code is further tweaked for a Cortex A8 core--with-float=hard: Generate opcodes for the floating point unit and uses the VFP registers for parameters--enable-threads=posix: Enable POSIX threads
These are the default settings for the compiler. You can override most of them on the gcc command line so, for example, if you want to compile for a different CPU, you can override the configured setting, –-with-cpu, by adding -mcpu to the command line, as follows:
$ arm-cortex_a8-linux-gnueabihf-gcc -mcpu=cortex-a5 helloworld.c -o helloworld
You can print out the the range of architecture-specific options available using --target-help, as follows:
$ arm-cortex_a8-linux-gnueabihf-gcc --target-help
You may be wondering if it matters whether or not you get the exact configuration right at the time you generate the toolchain if you can change it later on, and the answer depends on the way you anticipate using it. If you plan to create a new toolchain for each target, then it makes sense to set everything up at the beginning because it will reduce the risks of getting it wrong later on. Jumping ahead a little to Chapter 6, Selecting a Build System, I call this the Buildroot philosophy. If, on the other hand, you want to build a toolchain that is generic and you are prepared to provide the correct settings when you build for a particular target, then you should make the base toolchain generic, which is the way the Yocto Project handles things. The preceding examples follow the Buildroot philosophy.
The toolchain sysroot is a directory which contains subdirectories for libraries, header files, and other configuration files. It can be set when the toolchain is configured through --with-sysroot= or it can be set on the command line, using --sysroot=. You can see the location of the default sysroot by using -print-sysroot:
$ arm-cortex_a8-linux-gnueabi-gcc -print-sysroot /home/chris/x-tools/arm-cortex_a8-linux-gnueabihf/arm-cortex_a8-linux-gnueabihf/sysroot
You will find the following in the sysroot:
lib: Contains the shared objects for the C library and the dynamic linker/loader,ld-linuxusr/lib: the static library archives for the C library and any other libraries that may be installed subsequentlyusr/include: Contains the headers for all the librariesusr/bin: Contains the utility programs that run on the target, such as thelddcommand/usr/share: Used for localization and internationalizationsbin: Provides the ldconfig utility, used to optimize library loading paths
Plainly, some of these are needed on the development host to compile programs, and others – for example the shared libraries and ld-linux – are needed on the target at runtime.