5.2. Embryo Toolchain

5.2.1. Installation of the Embryo Toolchain

We will be building Binutils and GCC from a combined source tree using the GCC Top Level Makefile. For more information about the Top Level Makefile build system see: http://gcc.gnu.org/install/ and http://gcc.gnu.org/wiki/Top-Level Bootstrap/.

This system will allow us to perform a 3 stage bootstrap, which will compile Binutils and GCC three times, using the latest build of each package for each new build. The resulting toolchain will be completely free from the host system's toolchain features or limitations, resulting in a sterile place to begin our HLFS system.

Unpack both the binutils-2.17 and gcc-core-4.1.2 source tarballs but do not change directory. Then combine them in the same directory with the following commands:

mv gcc-4.1.2/ embryo-toolchain
mv -v binutils-2.17 embryo-toolchain/
cd embryo-toolchain/
ln -vs binutils-2.17/{bfd,binutils,gas,gprof,ld,opcodes} .

The binutils-2.17 directories are symbolically linked because the Binutils include directory must remain available, and seperate from GCC's include directory, for binutils-2.17 to compile correctly.

There are several reasons we need this compiler to use -fPIC by default, and at this stage. The start-files built and installed by this compiler will find their way into C library files, and in turn will find their way into the next toolchain. These need to be PIC to begin with the avoid text relocations later on. The libiberty.a library built in the next toolchain builds two versions when the --enable-shared configure option is used, a PIC and non-PIC version. The PIC version of the libiberty.a library is explicitly linked to shared libraries by the GCC build system. The non-PIC version of the libiberty.a library is explicitly linked to program files. In our environment the program files will be shared objects, but if linked to a non-PIC library then the program files will not be position independent. Using the -fPIC option on everything, including both versions of libiberty.a will help ensure our next toolchain builds itself correctly. The -fPIC option is not as ideal for program files as the -fPIE option, because the -fPIE option allows the program to be optimized better. But at this stage it is the simplest option to use, and will not reflect on to the performance of the final system. This also makes the “boostrap” build of this toolchain more important, even if your host system's toolchain has identical version numbers.

Furthermore, we are using the libssp.a static library to provide SSP functions during the early stages of the uClibc system. This library must also be PIC because it will be linked to shared libraries in the next toolchain.

Modify this GCC to use the -fPIC option by default with the following command:

cp -vi gcc/config/i386/linux.h{,.orig}
sed 's/^\(#define CC1_SPEC.*\)\("\)$/\1 %{fno-pic|fpic|fPIC:;:-fPIC}\2/' \
    gcc/config/i386/linux.h.orig > gcc/config/i386/linux.h

The GCC and Binutils documentation recommends building outside of the source directory in a dedicated build directory:

mkdir -v ../embryo-build/
cd ../embryo-build/

Prepare the toolchain for compilation:

../embryo-toolchain/configure --prefix=/tools \
    --with-local-prefix=/tools --disable-nls \
    --enable-languages=c --enable-checking \
    --disable-werror --enable-bootstrap

Compile the toolchain:

make

Install the toolchain:

make install

Some packages will use the cc command as the compiler. Create a symbolic link from gcc to cc so these packages will use the gcc program:

ln -vs gcc /tools/bin/cc

Now recompile a new linker program which will use /tools/lib as the default library search path, and install it with an alternate program name extention. We will need this new linker after the C library is installed to /tools, during the “Adjusting” phase, later in this chapter:

ln -vs stage3-bfd/ bfd
ln -vs stage3-libiberty/ libiberty
cp -va stage3-ld/ tools-ld
make -C tools-ld/ clean
make -C tools-ld/ LIB_PATH=/tools/lib CC=/tools/bin/gcc
make -C tools-ld/ CC=/tools/bin/gcc EXEEXT=-new install-exec-local

The stage3-bfd and stage3-libiberty directories are symbolically linked to places where the build system expects to find them. They contain static libraries needed to build the new linker. The stage3-ld directory is copied to a new directory so that the build directory remains intact, in case you choose to inspect it.