2004-05-03 11:59:46 +01:00
|
|
|
<?xml version="1.0" encoding="ISO-8859-1"?>
|
2007-03-21 18:42:58 +00:00
|
|
|
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
|
|
|
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
|
2004-05-03 11:59:46 +01:00
|
|
|
<!ENTITY % general-entities SYSTEM "../general.ent">
|
|
|
|
%general-entities;
|
|
|
|
]>
|
2006-01-22 13:13:52 +00:00
|
|
|
|
2004-05-03 11:59:46 +01:00
|
|
|
<sect1 id="ch-tools-toolchaintechnotes">
|
2006-01-22 13:13:52 +00:00
|
|
|
<?dbhtml filename="toolchaintechnotes.html"?>
|
|
|
|
|
|
|
|
<title>Toolchain Technical Notes</title>
|
|
|
|
|
|
|
|
<para>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
|
2008-12-05 20:46:02 +00:00
|
|
|
to at any time during the process.</para>
|
2006-01-22 13:13:52 +00:00
|
|
|
|
|
|
|
<para>The overall goal of <xref linkend="chapter-temporary-tools"/> is to
|
2009-07-29 22:34:16 +01:00
|
|
|
produce a temporary area that contains a known-good set of tools that can be
|
|
|
|
isolated from the host system. By using <command>chroot</command>, 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.</para>
|
2006-01-22 13:13:52 +00:00
|
|
|
|
2012-05-06 04:56:30 +01:00
|
|
|
<note>
|
2006-01-22 13:13:52 +00:00
|
|
|
<para>Before continuing, be aware of the name of the working platform,
|
2008-12-03 22:46:04 +00:00
|
|
|
often referred to as the target triplet. A simple way to determine the
|
|
|
|
name of the target triplet is to run the <command>config.guess</command>
|
|
|
|
script that comes with the source for many packages. Unpack the Binutils
|
|
|
|
sources and run the script: <userinput>./config.guess</userinput> and note
|
|
|
|
the output. For example, for a modern 32-bit Intel processor the
|
|
|
|
output will likely be <emphasis>i686-pc-linux-gnu</emphasis>.</para>
|
2006-01-22 13:13:52 +00:00
|
|
|
|
|
|
|
<para>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 <command>ld</command> 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
|
2008-12-03 22:46:04 +00:00
|
|
|
linker for a 32-bit Intel machine will be
|
|
|
|
<filename class="libraryfile">ld-linux.so.2</filename>.
|
|
|
|
A sure-fire way to determine the name of the dynamic linker is to
|
2006-01-22 13:13:52 +00:00
|
|
|
inspect a random binary from the host system by running:
|
|
|
|
<userinput>readelf -l <name of binary> | grep interpreter</userinput>
|
|
|
|
and noting the output. The authoritative reference covering all platforms
|
|
|
|
is in the <filename>shlib-versions</filename> file in the root of the Glibc
|
|
|
|
source tree.</para>
|
2012-05-06 04:56:30 +01:00
|
|
|
</note>
|
2006-01-22 13:13:52 +00:00
|
|
|
|
|
|
|
<para>Some key technical points of how the <xref
|
|
|
|
linkend="chapter-temporary-tools"/> build method works:</para>
|
|
|
|
|
|
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
2009-07-29 21:46:21 +01:00
|
|
|
<para>Slightly adjusting the name of the working platform, by changing the
|
|
|
|
"vendor" field target triplet by way of the
|
|
|
|
<envar>LFS_TGT</envar> 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.</para>
|
2006-01-22 13:13:52 +00:00
|
|
|
</listitem>
|
|
|
|
<listitem>
|
2009-11-16 15:57:08 +00:00
|
|
|
<para> The temporary libraries are cross-compiled. Because a
|
|
|
|
cross-compiler by its nature cannot rely on anything from its host
|
2009-11-16 16:55:06 +00:00
|
|
|
system, this method removes potential contamination of the target
|
2009-11-16 15:57:08 +00:00
|
|
|
system by lessening the chance of headers or libraries from the host
|
|
|
|
being incorporated into the new tools. Cross-compilation also allows for
|
|
|
|
the possibility of building both 32-bit and 64-bit libraries on 64-bit
|
|
|
|
capable hardware.</para>
|
2006-01-22 13:13:52 +00:00
|
|
|
</listitem>
|
|
|
|
<listitem>
|
2012-04-25 20:26:21 +01:00
|
|
|
<para>Careful manipulation of the GCC source tells the compiler which target
|
|
|
|
dynamic linker will be used.</para>
|
2006-01-22 13:13:52 +00:00
|
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
|
|
|
|
<para>Binutils is installed first because the <command>configure</command>
|
|
|
|
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.</para>
|
|
|
|
|
|
|
|
<para>Binutils installs its assembler and linker in two locations,
|
|
|
|
<filename class="directory">/tools/bin</filename> and <filename
|
2009-05-24 18:49:53 +01:00
|
|
|
class="directory">/tools/$LFS_TGT/bin</filename>. The tools in one
|
2006-01-22 13:13:52 +00:00
|
|
|
location are hard linked to the other. An important facet of the linker is
|
|
|
|
its library search order. Detailed information can be obtained from
|
|
|
|
<command>ld</command> by passing it the <parameter>--verbose</parameter>
|
|
|
|
flag. For example, an <userinput>ld --verbose | grep SEARCH</userinput>
|
|
|
|
will illustrate the current search paths and their order. It shows which
|
|
|
|
files are linked by <command>ld</command> by compiling a dummy program and
|
|
|
|
passing the <parameter>--verbose</parameter> switch to the linker. For example,
|
|
|
|
<userinput>gcc dummy.c -Wl,--verbose 2>&1 | grep succeeded</userinput>
|
|
|
|
will show all the files successfully opened during the linking.</para>
|
|
|
|
|
|
|
|
<para>The next package installed is GCC. An example of what can be
|
|
|
|
seen during its run of <command>configure</command> is:</para>
|
|
|
|
|
2009-07-29 21:46:21 +01:00
|
|
|
<screen><computeroutput>checking what assembler to use... /tools/i686-lfs-linux-gnu/bin/as
|
|
|
|
checking what linker to use... /tools/i686-lfs-linux-gnu/bin/ld</computeroutput></screen>
|
2005-02-19 22:16:42 +00:00
|
|
|
|
2006-01-22 13:13:52 +00:00
|
|
|
<para>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 <command>gcc</command>
|
|
|
|
itself, the same search paths are not necessarily used. To find out which
|
|
|
|
standard linker <command>gcc</command> will use, run:
|
|
|
|
<userinput>gcc -print-prog-name=ld</userinput>.</para>
|
|
|
|
|
|
|
|
<para>Detailed information can be obtained from <command>gcc</command> by
|
|
|
|
passing it the <parameter>-v</parameter> command line option while compiling
|
|
|
|
a dummy program. For example, <userinput>gcc -v dummy.c</userinput> will show
|
|
|
|
detailed information about the preprocessor, compilation, and assembly stages,
|
|
|
|
including <command>gcc</command>'s included search paths and their order.</para>
|
|
|
|
|
2012-04-25 20:26:21 +01:00
|
|
|
<para>Next installed are sanitized Linux API headers. These allow the standard
|
|
|
|
C library (Glibc) to interface with features that the Linux kernel will
|
|
|
|
provide.</para>
|
|
|
|
|
2006-01-22 13:13:52 +00:00
|
|
|
<para>The next package installed is Glibc. The most important considerations
|
|
|
|
for building Glibc are the compiler, binary tools, and kernel headers. The
|
2009-07-29 21:46:21 +01:00
|
|
|
compiler is generally not an issue since Glibc will always use the compiler
|
|
|
|
relating to the <parameter>--host</parameter> parameter passed to its
|
|
|
|
configure script, e.g. in our case,
|
|
|
|
<command>i686-lfs-linux-gnu-gcc</command>. 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 <command>configure</command>, check the contents of the
|
|
|
|
<filename>config.make</filename> file in the <filename
|
2006-01-22 13:13:52 +00:00
|
|
|
class="directory">glibc-build</filename> directory for all important details.
|
2009-07-29 21:46:21 +01:00
|
|
|
Note the use of <parameter>CC="i686-lfs-gnu-gcc"</parameter> to control which
|
|
|
|
binary tools are used and the use of the <parameter>-nostdinc</parameter> and
|
|
|
|
<parameter>-isystem</parameter> flags to control the compiler's include
|
2006-01-22 13:13:52 +00:00
|
|
|
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.</para>
|
|
|
|
|
|
|
|
<para>During the second pass of Binutils, we are able to utilize the
|
|
|
|
<parameter>--with-lib-path</parameter> configure switch to control
|
2012-04-25 20:26:21 +01:00
|
|
|
<command>ld</command>'s library search path.</para>
|
|
|
|
|
|
|
|
<para>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 <filename class="directory">/lib</filename> directory embedded into
|
|
|
|
them, which would defeat the goal of getting away from the host. From this
|
|
|
|
point onwards, the core toolchain is self-contained and self-hosted. The
|
|
|
|
remainder of the <xref linkend="chapter-temporary-tools"/> packages all build
|
|
|
|
against the new Glibc in <filename
|
|
|
|
class="directory">/tools</filename>.</para>
|
2006-01-22 13:13:52 +00:00
|
|
|
|
|
|
|
<para>Upon entering the chroot environment in <xref
|
|
|
|
linkend="chapter-building-system"/>, the first major package to be
|
|
|
|
installed is Glibc, due to its self-sufficient nature mentioned above.
|
|
|
|
Once this Glibc is installed into <filename
|
2009-07-29 21:46:21 +01:00
|
|
|
class="directory">/usr</filename>, we will perform a quick changeover of the
|
|
|
|
toolchain defaults, and then proceed in building the rest of the target
|
2006-01-22 13:13:52 +00:00
|
|
|
LFS system.</para>
|
|
|
|
|
2004-05-03 11:59:46 +01:00
|
|
|
</sect1>
|