Linux From Scratch - Version 6.5

Chapter 5. Constructing a Temporary System

5.2. Toolchain Technical Notes

This section explains some of the rationale and technical details
behind the overall build method. It is not essential to immediately
understand everything in this section. Most of this information will
be clearer after performing an actual build. This section can be
referred to at any time during the process.

The overall goal of Chapter 5
is to produce a temporary area that contains a known-good set of
tools that can be isolated from the host system. By using
chroot, the commands in
the remaining chapters will be contained within that environment,
ensuring a clean, trouble-free build of the target LFS system. The
build process has been designed to minimize the risks for new readers
and to provide the most educational value at the same time.

Important

Before continuing, be aware of the name of the working platform,
often referred to as the target triplet. A simple way to determine
the name of the target triplet is to run the config.guess script that comes
with the source for many packages. Unpack the Binutils sources and
run the script: ./config.guess and note the
output. For example, for a modern 32-bit Intel processor the output
will likely be i686-pc-linux-gnu.

Also be aware of the name of the platform's dynamic linker, often
referred to as the dynamic loader (not to be confused with the
standard linker ld
that is part of Binutils). The dynamic linker provided by Glibc
finds and loads the shared libraries needed by a program, prepares
the program to run, and then runs it. The name of the dynamic
linker for a 32-bit Intel machine will be ld-linux.so.2. A sure-fire way to determine the
name of the dynamic linker is to inspect a random binary from the
host system by running: readelf -l
<name of binary> | grep interpreter and
noting the output. The authoritative reference covering all
platforms is in the shlib-versions
file in the root of the Glibc source tree.

Slightly adjusting the name of the working platform, by
changing the "vendor" field target triplet by way of the
LFS_TGT variable, ensures that the
first build of Binutils and GCC produces a compatible
cross-linker and cross-compiler. Instead of producing binaries
for another architecture, the cross-linker and cross-compiler
will produce binaries compatible with the current hardware.

The temporary libraries are cross-compiled. This removes all
dependency on the host system, lessens the chance of headers or
libraries from the host corrupting the new tools and allows for
the possibility of building both 32-bit and 64-bit libraries on
64-bit capable hardware.

Careful manipulation of gcc's specs file tells the compiler which target
dynamic linker will be used

Binutils is installed first because the configure runs of both GCC and
Glibc perform various feature tests on the assembler and linker to
determine which software features to enable or disable. This is more
important than one might first realize. An incorrectly configured GCC
or Glibc can result in a subtly broken toolchain, where the impact of
such breakage might not show up until near the end of the build of an
entire distribution. A test suite failure will usually highlight this
error before too much additional work is performed.

Binutils installs its assembler and linker in two locations,
/tools/bin and /tools/$LFS_TGT/bin. The tools in one location are
hard linked to the other. An important facet of the linker is its
library search order. Detailed information can be obtained from
ld by passing it the
--verbose flag. For example,
an ld --verbose | grep
SEARCH will illustrate the current search paths and
their order. It shows which files are linked by ld by compiling a dummy program and
passing the --verbose switch
to the linker. For example, gcc
dummy.c -Wl,--verbose 2>&1 | grep succeeded
will show all the files successfully opened during the linking.

The next package installed is GCC. An example of what can be seen
during its run of configure is:

checking what assembler to use... /tools/i686-lfs-linux-gnu/bin/as
checking what linker to use... /tools/i686-lfs-linux-gnu/bin/ld

This is important for the reasons mentioned above. It also
demonstrates that GCC's configure script does not search the PATH
directories to find which tools to use. However, during the actual
operation of gcc
itself, the same search paths are not necessarily used. To find out
which standard linker gcc will use, run: gcc -print-prog-name=ld.

Detailed information can be obtained from gcc by passing it the -v command line option while compiling
a dummy program. For example, gcc -v
dummy.c will show detailed information about the
preprocessor, compilation, and assembly stages, including
gcc's included search
paths and their order.

The next package installed is Glibc. The most important
considerations for building Glibc are the compiler, binary tools, and
kernel headers. The compiler is generally not an issue since Glibc
will always use the compiler relating to the --host parameter passed to its
configure script, e.g. in our case, i686-lfs-linux-gnu-gcc. The binary
tools and kernel headers can be a bit more complicated. Therefore,
take no risks and use the available configure switches to enforce the
correct selections. After the run of configure, check the contents of
the config.make file in the
glibc-build directory for all important
details. Note the use of CC="i686-lfs-gnu-gcc" to control which
binary tools are used and the use of the -nostdinc and -isystem flags to control the
compiler's include search path. These items highlight an important
aspect of the Glibc package—it is very self-sufficient in terms
of its build machinery and generally does not rely on toolchain
defaults.

After the Glibc installation, change gcc's specs file to point to the
new dynamic linker in /tools/lib. This
last step is vital in ensuring that searching and linking take place
only within the /tools prefix. A
hard-wired path to a dynamic linker is embedded into every Executable
and Link Format (ELF)-shared executable. This can be inspected by
running: readelf -l <name of
binary> | grep interpreter. Amending gcc's specs file ensures that every
program compiled from here through the end of this chapter will use
the new dynamic linker in /tools/lib.

For the second pass of GCC, its sources also need to be modified to
tell GCC to use the new dynamic linker. Failure to do so will result
in the GCC programs themselves having the name of the dynamic linker
from the host system's /lib directory
embedded into them, which would defeat the goal of getting away from
the host.

During the second pass of Binutils, we are able to utilize the
--with-lib-path configure
switch to control ld's
library search path. From this point onwards, the core toolchain is
self-contained and self-hosted. The remainder of the Chapter 5
packages all build against the new Glibc in /tools.

Upon entering the chroot environment in Chapter
6, the first major package to be installed is Glibc, due to its
self-sufficient nature mentioned above. Once this Glibc is installed
into /usr, we will perform a quick
changeover of the toolchain defaults, and then proceed in building
the rest of the target LFS system.