Context Navigation

-              rc288d97
+              r90e3cb3
 <para>The build instructions assume that you are using the
 <userinput>bash</userinput> shell. It is also expected that you have already
+<command>bash</command> shell. It is also expected that you have already
 unpacked a source package (while logged in as user <emphasis>lfs</emphasis> --
 explained shortly) and performed a <userinput>cd</userinput> into the source
 …
 <filename class="directory">/lib</filename> directory on your host system. A
 surefire way is to inspect a random binary from your host system by running:
 <userinput>'readelf -l &lt;name of binary&gt; | grep interpreter'</userinput>
+<userinput>readelf -l &lt;name of binary&gt; | 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
 …
 choose.</para></listitem>
 <listitem><para>Careful manipulation of <userinput>gcc</userinput>'s
+<listitem><para>Careful manipulation of <command>gcc</command>'s
 <emphasis>specs</emphasis> file to tell the compiler which target dynamic
 linker will be used.</para></listitem>
 …
 <para>Binutils is installed first because both GCC and Glibc perform various
 feature tests on the assembler and linker during their respective runs of
 <userinput>./configure</userinput> to determine which software features to enable
+<command>./configure</command> 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
 …
 the tools in one location are hard linked to the other. An important facet of
 the linker is its library search order. Detailed information can be obtained
 from <userinput>ld</userinput> by passing it the <emphasis>--verbose</emphasis>
 flag. For example: <userinput>'ld --verbose | grep SEARCH'</userinput> will
+from <command>ld</command> by passing it the <emphasis>--verbose</emphasis>
+flag. For example: <command>ld --verbose | grep SEARCH</command> will
 show you the current search paths and their order. You can see what files are
 actually linked by <userinput>ld</userinput> by compiling a dummy program and
 passing the <emphasis>--verbose</emphasis> switch. For example:
 <userinput>'gcc dummy.c -Wl,--verbose 2>&amp;1 | grep succeeded'</userinput>
 will show you all the files successfully opened during the link.</para>
+actually linked by <command>ld</command> by compiling a dummy program and
+passing the <emphasis>--verbose</emphasis> switch to the linker. For example:
+<command>gcc dummy.c -Wl,--verbose 2>&amp;1 | grep succeeded</command>
+will show you all the files successfully opened during the linking.</para>
 <para>The next package installed is GCC and during its run of
 <userinput>./configure</userinput> you'll see, for example:</para>
+<command>./configure</command> you'll see, for example:</para>
 <blockquote><screen>checking what assembler to use... /tools/i686-pc-linux-gnu/bin/as
 …
 <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 <userinput>gcc</userinput>
+tools to use. However, during the actual operation of <command>gcc</command>
 itself, the same search paths are not necessarily used. You can find out which
 standard linker <userinput>gcc</userinput> will use by running:
 <userinput>'gcc -print-prog-name=ld'</userinput>.
 Detailed information can be obtained from <userinput>gcc</userinput> by passing
+standard linker <command>gcc</command> will use by running:
+<command>gcc -print-prog-name=ld</command>.
+Detailed information can be obtained from <command>gcc</command> by passing
 it the <emphasis>-v</emphasis> flag while compiling a dummy program. For
 example: <userinput>'gcc -v dummy.c'</userinput> will show you detailed
+example: <command>gcc -v dummy.c</command> will show you detailed
 information about the preprocessor, compilation and assembly stages, including
 <userinput>gcc</userinput>'s include search paths and their order.</para>
+<command>gcc</command>'s include search paths and their order.</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 no problem as Glibc will always use the <userinput>gcc</userinput>
+is generally no problem as Glibc will always use the <command>gcc</command>
 found in a $PATH directory. The binary tools and kernel headers can be a little
 more troublesome. Therefore we take no risks and use the available configure
 switches to enforce the correct selections. After the run of
 <userinput>./configure</userinput> you can check the contents of the
+<command>./configure</command> you can check the contents of the
 <filename>config.make</filename> file in the
 <filename class="directory">glibc-build</filename> directory for all the
 important details. You'll note some interesting items like the use of
 <userinput>CC="gcc -B/tools/bin/"</userinput> to control which binary tools are
+<emphasis>CC="gcc -B/tools/bin/"</emphasis> to control which binary tools are
 used, and also the use of the <emphasis>-nostdinc</emphasis> and
 <emphasis>-isystem</emphasis> flags to control the compiler's include search
 …
 <para>After the Glibc installation, we make some adjustments to ensure that
 searching and linking take place only within our <filename>/tools</filename>
 prefix. We install an adjusted <userinput>ld</userinput>, which has a hard-wired
+prefix. We install an adjusted <command>ld</command>, which has a hard-wired
 search path limited to <filename class="directory">/tools/lib</filename>. Then
 we amend <userinput>gcc</userinput>'s specs file to point to our new dynamic
+we amend <command>gcc</command>'s specs file to point to our new dynamic
 linker in <filename class="directory">/tools/lib</filename>. This last step is
 <emphasis>vital</emphasis> to the whole process. As mentioned above, a
 hard-wired path to a dynamic linker is embedded into every ELF shared
 executable. You can inspect this by running:
+<userinput>'readelf -l &lt;name of binary&gt; | grep interpreter'</userinput>.
+By amending <userinput>gcc</userinput>'s specs file, we are ensuring that every
+program compiled from here through the end of <xref linkend="chapter05"/> will
+use our new dynamic linker in
+<filename class="directory">/tools/lib</filename>.</para>
+<command>readelf -l &lt;name of binary&gt; | grep interpreter</command>.
+By amending <command>gcc</command>'s specs file, we are ensuring that every
+program compiled from here through the end of this chapter will use our new
+dynamic linker in <filename class="directory">/tools/lib</filename>.</para>
 <para>The need to use the new dynamic linker is also the reason why we apply the
 …
 <para>During the second pass of Binutils, we are able to utilize the
 <emphasis>--with-lib-path</emphasis> configure switch to control
 <userinput>ld</userinput>'s library search path. From this point onwards, the
+<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="chapter05"/> packages all build against the new Glibc in
 …
 <filename class="directory">/usr</filename>, we perform a quick changeover of
 the toolchain defaults, then proceed for real in building the rest of the
 target <xref linkend="chapter06"/> LFS system.</para>
+target LFS system.</para>
 <sect2>
 …
 <screen><userinput>ln -s $LFS/tools /</userinput></screen>
 <note><para>The above command is correct. The <userinput>ln</userinput> command
+<note><para>The above command is correct. The <command>ln</command> command
 has a few syntactic variations, so be sure to check the info page before
 reporting what you may think is an error.</para></note>
 …
 <screen><userinput>su - lfs</userinput></screen>
 <para>The "<userinput>-</userinput>" instructs <userinput>su</userinput> to
 start a <emphasis>login</emphasis> shell.</para>
+<para>The "<command>-</command>" instructs <command>su</command> to start a
+<emphasis>login</emphasis> shell.</para>
 </sect1>
 …
 <para>We're going to set up a good working environment by creating two new
 startup files for the <userinput>bash</userinput> shell. While logged in as
+startup files for the <command>bash</command> shell. While logged in as
 user <emphasis>lfs</emphasis>, issue the following command to create a new
 <filename>.bash_profile</filename>:</para>
 …
 <filename>/etc/profile</filename> of your host (probably containing some
 settings of environment variables) and then <filename>.bash_profile</filename>.
 The <userinput>exec env -i ... /bin/bash</userinput> command in the latter file
+The <command>exec env -i ... /bin/bash</command> command in the latter file
 replaces the running shell with a new one with a completely empty environment,
 except for the HOME, TERM and PS1 variables. This ensures that no unwanted and
 …
 <userinput>EOF</userinput></screen>
 <para>The <userinput>set +h</userinput> command turns off
 <userinput>bash</userinput>'s hash function. Normally hashing is a useful
 feature: <userinput>bash</userinput> uses a hash table to remember the
+<para>The <command>set +h</command> command turns off
+<command>bash</command>'s hash function. Normally hashing is a useful
+feature: <command>bash</command> uses a hash table to remember the
 full pathnames of executable files to avoid searching the PATH time and time
 again to find the same executable. However, we'd like the new tools to be
 used as soon as they are installed. By switching off the hash function, our
 "interactive" commands (<userinput>make</userinput>,
 <userinput>patch</userinput>, <userinput>sed</userinput>,
 <userinput>cp</userinput> and so forth) will always use
+"interactive" commands (<command>make</command>,
+<command>patch</command>, <command>sed</command>,
+<command>cp</command> and so forth) will always use
 the newest available version during the build process.</para>
 …
 You will need to investigate and retrace your steps to find out where the
 problem is and correct it. There is no point in continuing until this is done.
 First, redo the sanity check using <userinput>gcc</userinput> instead of
 <userinput>cc</userinput>. If this works it means the
+First, redo the sanity check using <command>gcc</command> instead of
+<command>cc</command>. If this works it means the
 <filename class="symlink">/tools/bin/cc</filename> symlink is missing. Revisit
 <xref linkend="ch-tools-gcc-pass1"/> and fix the symlink. Second, ensure your $PATH
 …
 <para>Take care <emphasis>not</emphasis> to use
 <userinput>--strip-unneeded</userinput> on the libraries -- they would be
+<emphasis>--strip-unneeded</emphasis> on the libraries -- they would be
 destroyed and you would have to build Glibc all over again.</para>

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

Context Navigation

Changeset 90e3cb3 for chapter05/chapter05.xml

Legend:

chapter05/chapter05.xml

Download in other formats: