diff options
Diffstat (limited to 'chapter05/toolchaintechnotes.xml')
| -rw-r--r-- | chapter05/toolchaintechnotes.xml | 91 |
1 files changed, 17 insertions, 74 deletions
diff --git a/chapter05/toolchaintechnotes.xml b/chapter05/toolchaintechnotes.xml index 2932b957f..398f3d104 100644 --- a/chapter05/toolchaintechnotes.xml +++ b/chapter05/toolchaintechnotes.xml @@ -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> |