Author: jhuntwork
Date: 2012-04-23 11:59:09 -0600 (Mon, 23 Apr 2012)
New Revision: 9826
Modified:
branches/jh/chapter01/changelog.xml
branches/jh/chapter05/toolchaintechnotes.xml
branches/jh/general.ent
Log:
Update chapter 5 toolchain technical notes to match build method.
Modified: branches/jh/chapter01/changelog.xml
===================================================================
--- branches/jh/chapter01/changelog.xml 2012-04-23 16:32:38 UTC (rev 9825)
+++ branches/jh/chapter01/changelog.xml 2012-04-23 17:59:09 UTC (rev 9826)
@@ -36,7 +36,18 @@
</listitem>
-->
+
<listitem>
+ <para>2012-04-23</para>
+ <itemizedlist>
+ <listitem>
+ <para>[jhuntwork] - Update chapter 5 toolchain technical notes to
match changes
+ in build method.</para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+
+ <listitem>
<para>2012-04-22</para>
<itemizedlist>
<listitem>
Modified: branches/jh/chapter05/toolchaintechnotes.xml
===================================================================
--- branches/jh/chapter05/toolchaintechnotes.xml 2012-04-23 16:32:38 UTC
(rev 9825)
+++ branches/jh/chapter05/toolchaintechnotes.xml 2012-04-23 17:59:09 UTC
(rev 9826)
@@ -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 @@
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,28 +139,16 @@
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>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.</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,
+ 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>
@@ -170,52 +161,4 @@
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>
Modified: branches/jh/general.ent
===================================================================
--- branches/jh/general.ent 2012-04-23 16:32:38 UTC (rev 9825)
+++ branches/jh/general.ent 2012-04-23 17:59:09 UTC (rev 9826)
@@ -1,5 +1,5 @@
-<!ENTITY version "JH-20120422">
-<!ENTITY releasedate "Apr 22, 2012">
+<!ENTITY version "JH-20120423">
+<!ENTITY releasedate "Apr 23, 2012">
<!ENTITY copyrightdate "1999-2012"><!-- jhalfs needs a literal dash, not
– -->
<!ENTITY milestone "7.2">
<!ENTITY generic-version "development"> <!-- Use "development", "testing", or
"x.y[-pre{x}]" -->
--
http://linuxfromscratch.org/mailman/listinfo/lfs-book
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
