|
Building Software
Building open source software like the toolchain involves using a piece of software called Autoconf. This software (which itself is quite complex) creates a make file after running a script called configure that inspects the system where the build occurs. When running configure, you pass in parameters describing how to build the software for which the configure script can't use a reasonable default. Some of the most confusing parameters passed into configure are the values for host, target, and build. These parameters are called configuration names, or triplets, despite the fact that they now contain four parts. When you're building a toolchain, the triplet describing the target machine is the four-part variety: for example, arm-none-linux-gnueabi. This unwieldy string prefixes the name of the toolchain executables so it's clear what the cross-compiler is targeting. It's possible to change this prefix, but the best practice is to leave it be. Many users get flustered about what to pick for their processor. The acceptable values for this field are always in flux, and experimentation is a reasonable approach to verify that the triplet is acceptable.
Another thing that is different from other open source packages is that the glibc and libc configuration steps must be done from a directory other than one where the source code files reside. Although the directory can be any one other than where the source resides, the best practice is to create an empty directory and run the configuration program from the newly created directory. One of the great advantages of this practice is that creating a clean build environment is just an rm -rf <build directory> away. Given the experimental nature of building toolchains, being able to start from scratch when building is a great convenience.
Get Comfortable with the Command Line
The engineers who build and maintain the kernel, compiler, and libraries work from the command-line, because it's the lingua franca of the Linux world. This doesn't show a bias against using IDE tools; years, and in some cases decades, of time and effort have gone into making the command line efficient and productive. After these tools have been built, several graphical environments know how to use them, so time spent at the command prompt is minimized. These examples use the bash shell. Nearly all distributions use this shell by default. The vast majority of users have graphical desktops, and you run the shell by selecting it from the menu; for example, in Ubuntu, you can start the shell by selecting Applications > Accessories > Terminal from the main menu. If you can't locate the shell on the menu, press the Alt+F2 key combination. On both Gnome and KDE, you're prompted for a program to run; you want to use /bin/bash. Also, be sure to select the “Run in terminal”2 check box (or the equivalent for your window manager); otherwise, you won't see your shell. If you're new to the command line, a great hint is to open several command-line terminal windows. This makes it easy to experiment in one window and use another check on the results. A terminal window requires very few resources, so there's no need to economize on the number open at any one point as long as confusion is kept at bay.
Building a GCC Cross-Compiler
Building GCC involves fetching the sources for several projects, getting them ready for compilation, and then running the compile. The entire process with a reasonably fast computer takes an hour or and requires about 500GB of disk space. In the process, GCC is built twice. An overview of the steps follows:
1. Gather the sources. There are two ways to get the source code for a project: get the sources from version control, or fetch source snapshots created when the software is released. If you're planning to contribute to the development efforts of the projects used in the construction of a toolchain, using source controls is the route you should take; otherwise, you should use the source snapshots. No matter how you plan to get the sources, fetching the source code over a slow connection can sometimes require an hour.
2. Build the binutils. The binutils (binary utilities) provide low-level handling of binary files, such as linking, assembling, and parsing ELF files. The GCC compiler depends on these tools to create an executable, because it generates object files that binutils assemble into an executable image.
3. Build a bootstrap GCC. You build GCC once with minimal settings so that it can be used to then build the C Standard Library - in this case, GNU C Standard Library (glibc). The bootstrap compiler has no such library: it can be used to compile C code, but the functions that most C programmers depend on to interact with the underlying machine, such as opening a file or printing output, don't exist for this compiler.
4. Use the bootstrap GCC to build the glibc library. With the C library, you have a tool you can use to build an executable that runs on the target system. It has the code that opens files, reads, writes, and otherwise functions as you expect when you're using C.
The C Library
In this article you build a Linux toolchain with the GNU C Library. This is the library running on the vast majority of desktop Linux machines, and it's the most complete implementation of the C Library for Linux systems. You may even say it's the canonical implementation. The process for building a toolchain that uses a different library, like dietlibc, newlib, or uClibc, follows the same pattern of creating a bootstrap compiler, then building the libraries, and then rebuilding the compiler. The GNU C Library (glibc) is the most ornery to build and get working. After you pass the glibc trial, getting newlib or another library built is much easier.
Gathering Sources
There are two ways to get the sources: download distribution tars or get the source directly from source control. If you're planning to participate in the development of these projects, get the files from source control, because this is the easiest way to contribute patches and stay current with the development process. If you're planning to use the sources to make a build, and you aren't interested in contributing to the projects, skip the part where the files are fetched as tar archives. Before you download a bunch of open source projects in your home directory, create a new directory to hold these files so you can stay organized.