Context Navigation

-              re625c49
+              r1a3e6a3
     </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>
 …
   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
 …
   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 &lt;name of binary&gt; | 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
 …
   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&mdash;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&mdash;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>

Note: See TracChangeset for help on using the changeset viewer.

Context Navigation

Changeset 1a3e6a3 for chapter05/toolchaintechnotes.xml

Legend:

chapter05/toolchaintechnotes.xml

Download in other formats: