|
@@ -71,9 +71,8 @@
|
|
|
capable hardware.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
- <para>Careful manipulation of <command>gcc</command>'s
|
|
|
- <filename>specs</filename> file tells the compiler which target dynamic
|
|
|
- linker will be used</para>
|
|
|
+ <para>Careful manipulation of the GCC source tells the compiler which target
|
|
|
+ dynamic linker will be used.</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
|
|
@@ -118,6 +117,10 @@ checking what linker to use... /tools/i686-lfs-linux-gnu/bin/ld</computeroutput>
|
|
|
detailed information about the preprocessor, compilation, and assembly stages,
|
|
|
including <command>gcc</command>'s included search paths and their order.</para>
|
|
|
|
|
|
+ <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>
|
|
|
+
|
|
|
<para>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
|
|
@@ -136,31 +139,19 @@ checking what linker to use... /tools/i686-lfs-linux-gnu/bin/ld</computeroutput>
|
|
|
package—it is very self-sufficient in terms of its build machinery and
|
|
|
generally does not rely on toolchain defaults.</para>
|
|
|
|
|
|
- <para>After the Glibc installation, change <command>gcc</command>'s specs file
|
|
|
- to point to the new dynamic linker in <filename
|
|
|
- class="directory">/tools/lib</filename>. This last step is vital in ensuring
|
|
|
- that searching and linking take place only within the <filename
|
|
|
- class="directory">/tools</filename> 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:
|
|
|
- <userinput>readelf -l <name of binary> | grep interpreter</userinput>.
|
|
|
- Amending <command>gcc</command>'s specs file ensures that every program
|
|
|
- compiled from here through the end of this chapter will use the new dynamic
|
|
|
- linker in <filename class="directory">/tools/lib</filename>.</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.</para>
|
|
|
-
|
|
|
<para>During the second pass of Binutils, we are able to utilize the
|
|
|
<parameter>--with-lib-path</parameter> configure switch to control
|
|
|
- <command>ld</command>'s library search path. 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>
|
|
|
+ <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>
|
|
|
|
|
|
<para>Upon entering the chroot environment in <xref
|
|
|
linkend="chapter-building-system"/>, the first major package to be
|
|
@@ -170,52 +161,4 @@ checking what linker to use... /tools/i686-lfs-linux-gnu/bin/ld</computeroutput>
|
|
|
toolchain defaults, and then proceed in building the rest of the target
|
|
|
LFS system.</para>
|
|
|
|
|
|
- <!-- FIXME: Removed as part of the fix for bug 1061 - we no longer build pass1
|
|
|
- packages statically, therefore this explanation isn't required
|
|
|
-
|
|
|
- <sect2>
|
|
|
- <title>Notes on Static Linking</title>
|
|
|
-
|
|
|
- <para>Besides their specific task, most programs have to perform many
|
|
|
- common and sometimes trivial operations. These include allocating
|
|
|
- memory, searching directories, reading and writing files, string
|
|
|
- handling, pattern matching, arithmetic, and other tasks. Instead of
|
|
|
- obliging each program to reinvent the wheel, the GNU system provides
|
|
|
- all these basic functions in ready-made libraries. The major library
|
|
|
- on any Linux system is Glibc.</para>
|
|
|
-
|
|
|
- <para>There are two primary ways of linking the functions from a
|
|
|
- library to a program that uses them—statically or dynamically. When
|
|
|
- a program is linked statically, the code of the used functions is
|
|
|
- included in the executable, resulting in a rather bulky program. When
|
|
|
- a program is dynamically linked, it includes a reference to the
|
|
|
- dynamic linker, the name of the library, and the name of the function,
|
|
|
- resulting in a much smaller executable. A third option is to use the
|
|
|
- programming interface of the dynamic linker (see <filename>dlopen(3)</filename>
|
|
|
- for more information).</para>
|
|
|
-
|
|
|
- <para>Dynamic linking is the default on Linux and has three major
|
|
|
- advantages over static linking. First, only one copy of the executable
|
|
|
- library code is needed on the hard disk, instead of having multiple
|
|
|
- copies of the same code included in several programs, thus saving
|
|
|
- disk space. Second, when several programs use the same library
|
|
|
- function at the same time, only one copy of the function's code is
|
|
|
- required in core, thus saving memory space. Third, when a library
|
|
|
- function gets a bug fixed or is otherwise improved, only the one
|
|
|
- library needs to be recompiled instead of recompiling all programs
|
|
|
- that make use of the improved function.</para>
|
|
|
-
|
|
|
- <para>If dynamic linking has several advantages, why then do we
|
|
|
- statically link the first two packages in this chapter? The reasons
|
|
|
- are threefold—historical, educational, and technical. The
|
|
|
- historical reason is that earlier versions of LFS statically linked
|
|
|
- every program in this chapter. Educationally, knowing the difference
|
|
|
- between static and dynamic linking is useful. The technical benefit is
|
|
|
- a gained element of independence from the host, meaning that those
|
|
|
- programs can be used independently of the host system. However, it is
|
|
|
- worth noting that an overall successful LFS build can still be
|
|
|
- achieved when the first two packages are built dynamically.</para>
|
|
|
-
|
|
|
- </sect2>-->
|
|
|
-
|
|
|
</sect1>
|