Context Navigation

-              rb711e1d
+              r574b0ea
 <para>From this point onwards everything will link <emphasis>only</emphasis>
 against the libraries in <filename>/tools/lib</filename>.</para>
+against the libraries in <filename class="directory">/tools/lib</filename>.</para>
 <note><para>If you somehow missed the earlier warning to retain the Binutils
 …
 in dynamic linker name):</para>
 <blockquote><screen>[Requesting program interpreter: /tools/lib/ld-linux.so.2]</screen></blockquote>
+<blockquote><screen><computeroutput>[Requesting program interpreter: /tools/lib/ld-linux.so.2]</computeroutput></screen></blockquote>
 <para>Note especially that <filename class="directory">/tools/lib</filename>

chapter05/binutils-pass1.xml

-              rb711e1d
+              r574b0ea
 <para>This package is known to behave badly when you change its default
 optimization flags (including the <emphasis>-march</emphasis> and
 <emphasis>-mcpu</emphasis> options). Therefore, if you have defined any
+optimization flags (including the <parameter>-march</parameter> and
+<parameter>-mcpu</parameter> options). Therefore, if you have defined any
 environment variables that override default optimizations, such as CFLAGS and
 CXXFLAGS, we recommend un-setting them when building Binutils.</para>
 …
 <variablelist>
 <varlistentry>
 <term><userinput>--prefix=/tools</userinput></term>
+<term><parameter>--prefix=/tools</parameter></term>
 <listitem><para>This tells the configure script to prepare to install the Binutils
 programs in the <filename>/tools</filename> directory.</para></listitem>
+programs in the <filename class="directory">/tools</filename> directory.</para></listitem>
 </varlistentry>
 <varlistentry>
 <term><userinput>--disable-nls</userinput></term>
+<term><parameter>--disable-nls</parameter></term>
 <listitem><para>This disables internationalization (a word often shortened to
 i18n). We don't need this for our static programs and <emphasis>nls</emphasis>
 …
 <variablelist>
 <varlistentry>
 <term><userinput>configure-host</userinput></term>
+<term><parameter>configure-host</parameter></term>
 <listitem><para>This forces all the subdirectories to be configured immediately.
 A statically linked build will fail without it. We therefore use this option to work
 …
 <varlistentry>
 <term><userinput>LDFLAGS="-all-static"</userinput></term>
+<term><parameter>LDFLAGS="-all-static"</parameter></term>
 <listitem><para>This tells the linker that all the Binutils programs should be
 linked statically. However, strictly speaking, <emphasis>"-all-static"</emphasis>
+linked statically. However, strictly speaking, <parameter>"-all-static"</parameter>
 is passed to the <command>libtool</command> program, which then passes
 <emphasis>"-static"</emphasis> to the linker.</para></listitem>
+<parameter>"-static"</parameter> to the linker.</para></listitem>
 </varlistentry>
 </variablelist>
 …
 <variablelist>
 <varlistentry>
 <term><userinput>-C ld clean</userinput></term>
+<term><parameter>-C ld clean</parameter></term>
 <listitem><para>This tells the make program to remove all the compiled files
 in the <filename class="directory">ld</filename> subdirectory.</para></listitem>
 …
 <varlistentry>
 <term><userinput>-C ld LDFLAGS="-all-static"
 LIB_PATH=/tools/lib</userinput></term>
+<term><parameter>-C ld LDFLAGS="-all-static"
+LIB_PATH=/tools/lib</parameter></term>
 <listitem><para>This option rebuilds everything in the
 <filename class="directory">ld</filename> subdirectory. Specifying the LIB_PATH

chapter05/binutils-pass2.xml

-              rb711e1d
+              r574b0ea
 <variablelist>
 <varlistentry>
 <term><userinput>--with-lib-path=/tools/lib</userinput></term>
+<term><parameter>--with-lib-path=/tools/lib</parameter></term>
 <listitem><para>This tells the configure script to specify the library search path
 during the compilation of Binutils, resulting in <emphasis>/tools/lib</emphasis>
+during the compilation of Binutils, resulting in <parameter>/tools/lib</parameter>
 to be passed to the linker. This prevents the linker from searching through library
 directories on the host.</para></listitem>
 …
 exceptions to this rule are as follows:</para>
 <screen>* 5 FAIL (unexpected failure) for visibility
+<screen><computeroutput>* 5 FAIL (unexpected failure) for visibility
 * 1 FAIL for selective4
 * 1 FAIL for selective5</screen>
+* 1 FAIL for selective5</computeroutput></screen>
 <!--
 …
 to spot. The output shown will contain something like:</para>
 <blockquote><screen>make[1]: *** [check-binutils] Error 2</screen></blockquote>
+<blockquote><screen><computeroutput>make[1]: *** [check-binutils] Error 2</computeroutput></screen></blockquote>
 -->
 …
 <screen><userinput>make install</userinput></screen>
 <para>Now prepare the linker for the "Re-adjusting" phase in the next
+<para>Now prepare the linker for the <quote>Re-adjusting</quote> phase in the next
 chapter:</para>

chapter05/coreutils.xml

-              rb711e1d
+              r574b0ea
 <screen><userinput>DEFAULT_POSIX2_VERSION=199209 ./configure --prefix=/tools</userinput></screen>
 <para>This package has an issue when compiled against versions of glibc
+<para>This package has an issue when compiled against versions of Glibc
 later than 2.3.2.  Some of the Coreutils utilities (such as
 (<command>head</command>, <command>tail</command> and <command>sort</command>)
 …
 should be preserved until the many places where it is used can be
 updated.  Backwards compatibility is achieved by setting the
 DEFAULT_POSIX2_VERSION environment variable to &quot;199209&quot; in the above
 command.  If you don&apos;t want coreutils to be backwards compatible
+DEFAULT_POSIX2_VERSION environment variable to <quote>199209</quote> in the above
+command.  If you don't want coreutils to be backwards compatible
 with the traditional syntax, then simply omit setting the DEFAULT_POSIX2_VERSION
 environment variable.  Realise though, that doing so will mean you&apos;ll have
+environment variable.  Realise though, that doing so will mean you'll have
 to deal with the consequences yourself: patch the many packages that still use
 the old syntax.  We therefore recommend using the instructions exactly as given
 …
 <para>(If you insist on testing the results, then issue:
 <userinput>make RUN_EXPENSIVE_TESTS=yes check</userinput>. The
 <emphasis>RUN_EXPENSIVE_TESTS=yes</emphasis> parameter tells the test suite to
+<parameter>RUN_EXPENSIVE_TESTS=yes</parameter> parameter tells the test suite to
 run several additional tests that are considered relatively expensive on some
 platforms but generally are not a problem on Linux.)</para>

chapter05/dejagnu.xml

rb711e1d	r574b0ea
54	54	<indexterm zone="ch-tools-dejagnu runtest"><primary sortas="b-runtest">runtest</primary></indexterm>
55	55	<para>is the wrapper script that finds the proper
56		~~expect~~ shell and then runs DejaGnu.</para>
	56	<command>expect</command> shell and then runs DejaGnu.</para>
57	57	</listitem>
58	58	</varlistentry>

chapter05/expect.xml

-              rb711e1d
+              r574b0ea
 <variablelist>
 <varlistentry>
 <term><userinput>--with-tcl=/tools/lib</userinput></term>
+<term><parameter>--with-tcl=/tools/lib</parameter></term>
 <listitem><para>This ensures that
 the configure script finds the Tcl installation in our temporary tools location.
 …
 <varlistentry>
 <term><userinput>--with-x=no</userinput></term>
+<term><parameter>--with-x=no</parameter></term>
 <listitem><para>This tells the configure
 script not to search for Tk (the Tcl GUI component) or the X Window System
 …
 <variablelist>
 <varlistentry>
 <term><userinput>SCRIPTS=""</userinput></term>
+<term><parameter>SCRIPTS=""</parameter></term>
 <listitem><para>This prevents installation
 of the supplementary expect scripts which are not needed.</para></listitem>

chapter05/gcc-pass1.xml

-              rb711e1d
+              r574b0ea
 <para>This package is known to behave badly when you change its default
 optimization flags (including the <emphasis>-march</emphasis> and
 <emphasis>-mcpu</emphasis> options). Therefore, if you have defined any
+optimization flags (including the <parameter>-march</parameter> and
+<parameter>-mcpu</parameter> options). Therefore, if you have defined any
 environment variables that override default optimizations, such as CFLAGS and
 CXXFLAGS, we recommend un-setting them when building GCC.</para>
 …
 <variablelist>
 <varlistentry>
 <term><userinput>--with-local-prefix=/tools</userinput></term>
 <listitem><para>The purpose of this switch is to remove <filename>/usr/local/include</filename>
+<term><parameter>--with-local-prefix=/tools</parameter></term>
+<listitem><para>The purpose of this switch is to remove <filename class="directory">/usr/local/include</filename>
 from <command>gcc</command>'s include search path. This is not absolutely
 essential; however, we want to try to minimize the influence of the host
 …
 <varlistentry>
 <term><userinput>--enable-shared</userinput></term>
+<term><parameter>--enable-shared</parameter></term>
 <listitem><para>This switch may
 seem counter-intuitive at first. But using it allows the building of
 …
 having <filename>libgcc_eh.a</filename> available ensures that the configure
 script for Glibc (the next package we compile) produces the proper results.
 Note that the <command>gcc</command> binaries will still be linked
 statically, as this is controlled by the <emphasis>-static</emphasis>
+Note that the GCC binaries will still be linked
+statically, as this is controlled by the <parameter>-static</parameter>
 value of BOOT_LDFLAGS in the next step.</para></listitem>
 </varlistentry>
 <varlistentry>
 <term><userinput>--enable-languages=c</userinput></term>
+<term><parameter>--enable-languages=c</parameter></term>
 <listitem><para>This option
 ensures that only the C compiler is built. The option is only needed when you
 …
 <variablelist>
 <varlistentry>
 <term><userinput>BOOT_LDFLAGS="-static"</userinput></term>
+<term><parameter>BOOT_LDFLAGS="-static"</parameter></term>
 <listitem><para>This tells GCC to link its programs statically.</para></listitem>
 </varlistentry>
 <varlistentry>
 <term><userinput>bootstrap</userinput></term>
+<term><parameter>bootstrap</parameter></term>
 <listitem><para>This target doesn't just
 compile GCC, but compiles it several times. It uses the programs compiled in

chapter05/gcc-pass2.xml

-              rb711e1d
+              r574b0ea
 highly dependent on properly functioning pseudo terminals (PTYs) which are
 provided by your host. These days, PTYs are most commonly implemented via the
 <emphasis>devpts</emphasis> file system. You can quickly check if your host
+<systemitem class="filesystem">devpts</systemitem> file system. You can quickly check if your host
 system is set up correctly in this regard by performing a simple test:</para>
 …
 <para>The response might be:</para>
 <blockquote><screen>The system has no more ptys.  Ask your system administrator to create more.</screen></blockquote>
+<blockquote><screen><computeroutput>The system has no more ptys.  Ask your system administrator to create more.</computeroutput></screen></blockquote>
 <para>If you receive the above message, your host doesn't have its PTYs set up
 …
 to unpack both the core and the g++ tarballs (and testsuite too, if you want to
 run the tests). Unpacking them in your working directory, they will all unfold
 into a single <filename>gcc-&gcc-version;/</filename> subdirectory.</para>
+into a single <filename class="directory">gcc-&gcc-version;/</filename> subdirectory.</para>
 <para>First correct a problem and make an essential adjustment:</para>
 …
 patch -Np1 -i ../gcc-&gcc-short-version;-specs-1.patch</userinput></screen>
 <para>The first patch disables the GCC <quote>fixincludes</quote> script. We
+<para>The first patch disables the GCC <command>fixincludes</command> script. We
 mentioned this briefly earlier, but a slightly more in-depth explanation of
 the fixincludes process is warranted here. Under normal circumstances, the GCC
 fixincludes script scans your system for header files that need to be fixed. It
+<command>fixincludes</command> script scans your system for header files that need to be fixed. It
 might find that some Glibc header files on your host system need to be fixed,
 fix them and put them in the GCC private include directory. Then, later on in
 …
 <variablelist>
 <varlistentry>
 <term><userinput>--enable-clocale=gnu</userinput></term>
+<term><parameter>--enable-clocale=gnu</parameter></term>
 <listitem><para>This option
 ensures the correct locale model is selected for the C++ libraries under all
 …
 <varlistentry>
 <term><userinput>--enable-threads=posix</userinput></term>
+<term><parameter>--enable-threads=posix</parameter></term>
 <listitem><para>This enables
 C++ exception handling for multi-threaded code.</para></listitem>
 …
 <varlistentry>
 <term><userinput>--enable-__cxa_atexit</userinput></term>
+<term><parameter>--enable-__cxa_atexit</parameter></term>
 <listitem><para>This option
 allows use of __cxa_atexit, rather than atexit, to register C++ destructors for
 …
 <varlistentry>
 <term><userinput>--enable-languages=c,c++</userinput></term>
+<term><parameter>--enable-languages=c,c++</parameter></term>
 <listitem><para>This option
 ensures that both the C and C++ compilers are built.</para></listitem>
 …
 <varlistentry>
 <term><userinput>--disable-libstdcxx-pch</userinput></term>
+<term><parameter>--disable-libstdcxx-pch</parameter></term>
 <listitem><para>Don't build the
 PCH (pre-compiled header) for libstdc++. It takes up a ton of space, and we
 …
 <screen><userinput>make</userinput></screen>
 <para>There is no need to use the <emphasis>bootstrap</emphasis> target now,
+<para>There is no need to use the <parameter>bootstrap</parameter> target now,
 as the compiler we're using to compile this GCC was built from the exact same
 version of the GCC sources we used earlier.</para>
 …
 <screen><userinput>make -k check</userinput></screen>
 <para>The <emphasis>-k</emphasis> flag is used to make the test suite run
+<para>The <parameter>-k</parameter> flag is used to make the test suite run
 through to completion and not stop at the first failure. The GCC test suite is
 very comprehensive and is almost guaranteed to generate a few failures. To get

chapter05/gettext.xml

-              rb711e1d
+              r574b0ea
 <variablelist>
 <varlistentry>
 <term><userinput>--disable-libasprintf</userinput></term>
+<term><parameter>--disable-libasprintf</parameter></term>
 <listitem><para>This flag tells
 Gettext that we don't want its asprintf library.  Nothing in Chapter 5 or 6
 requires this, and gettext gets rebuilt later, so we exclude it to save
+Gettext that we don't want its asprintf library.  Nothing in this chapter or the next
+requires this, and Gettext gets rebuilt later, so we exclude it to save
 time/space.</para></listitem>
 </varlistentry>
 <varlistentry>
 <term><userinput>--disable-csharp</userinput></term>
+<term><parameter>--disable-csharp</parameter></term>
 <listitem><para>Gettext has a nasty
 habit of searching for a C# compiler on the host, and building bindings for it.

chapter05/glibc.xml

-              rb711e1d
+              r574b0ea
 <para>This package is known to behave badly when you change its default
 optimization flags (including the <emphasis>-march</emphasis> and
 <emphasis>-mcpu</emphasis> options). Therefore, if you have defined any
+optimization flags (including the <parameter>-march</parameter> and
+<parameter>-mcpu</parameter> options). Therefore, if you have defined any
 environment variables that override default optimizations, such as CFLAGS and
 CXXFLAGS, we recommend un-setting them when building Glibc.</para>
 …
 <variablelist>
 <varlistentry>
 <term><userinput>--disable-profile</userinput></term>
+<term><parameter>--disable-profile</parameter></term>
 <listitem><para>This builds the
 libraries without profiling information. Omit this option if you plan to do
 …
 <varlistentry>
 <term><userinput>--enable-add-ons=nptl</userinput></term>
+<term><parameter>--enable-add-ons=nptl</parameter></term>
 <listitem><para>This tells Glibc to use the NPTL add-on as its threading
 library.</para></listitem>
 …
 <varlistentry>
 <term><userinput>--with-tls</userinput></term>
+<term><parameter>--with-tls</parameter></term>
 <listitem><para>This tells Glibc to include support for TLS (thread-local storage).
 This is required for NPTL to work. </para></listitem>
 …
 <varlistentry>
 <term><userinput>--with-binutils=/tools/bin</userinput></term>
+<term><parameter>--with-binutils=/tools/bin</parameter></term>
 <listitem><para>Strictly speaking this switch is not required. But it does ensure
 nothing can go wrong with regard to what Binutils programs get used during the
 …
 <varlistentry>
 <term><userinput>--without-gd</userinput></term>
+<term><parameter>--without-gd</parameter></term>
 <listitem><para>This prevents the build of the <command>memusagestat</command>
 program, which strangely enough insists on linking against the host's libraries
 …
 <varlistentry>
 <term><userinput>--without-cvs</userinput></term>
+<term><parameter>--without-cvs</parameter></term>
 <listitem><para>This is meant to prevent
 the Makefiles from attempting automatic CVS checkouts when using a CVS
 …
 <varlistentry>
 <term><userinput>--with-headers=/tools/glibc-kernheaders</userinput></term>
+<term><parameter>--with-headers=/tools/glibc-kernheaders</parameter></term>
 <listitem><para>This tells Glibc to compile against the <quote>raw</quote>
 kernel headers, so that it knows exactly what features the kernel has, and can
 …
 <para>During this stage you might see the following warning:</para>
 <blockquote><screen>configure: WARNING:
+<blockquote><screen><computeroutput>configure: WARNING:
 *** These auxiliary programs are missing or incompatible versions: msgfmt
 *** some features will be disabled.
 *** Check the INSTALL file for required versions.</screen></blockquote>
+*** Check the INSTALL file for required versions.</computeroutput></screen></blockquote>
 <para>The missing or incompatible <command>msgfmt</command> program is
 …
 <listitem><para>The <emphasis>atime</emphasis> test sometimes fails when the
 LFS partition is mounted with the <emphasis>noatime</emphasis> option, or due
+LFS partition is mounted with the <parameter>noatime</parameter> option, or due
 to other file system quirks.</para></listitem>
 <listitem><para>The <emphasis>shm</emphasis> test might fail when the host
 system is running the devfs file system but doesn't have the tmpfs file system
 mounted at <filename>/dev/shm</filename> due to lack of support for tmpfs in
+system is running the devfs file system but doesn't have the <systemitem class="filesystem">tmpfs</systemitem> file system
+mounted at <filename class="directory">/dev/shm</filename> due to lack of support for tmpfs in
 the kernel.</para></listitem>

chapter05/grep.xml

-              rb711e1d
+              r574b0ea
 <variablelist>
 <varlistentry>
 <term><userinput>--disable-perl-regexp</userinput></term>
+<term><parameter>--disable-perl-regexp</parameter></term>
 <listitem><para>This makes sure that <command>grep</command> does not
 get linked against a PCRE library that may be present on the host and would not be
 …
 <varlistentry>
 <term><userinput>--with-included-regex</userinput></term>
+<term><parameter>--with-included-regex</parameter></term>
 <listitem><para>This ensures that
 Grep uses its internal regular expression code. Without this switch, Grep will

chapter05/hostreqs.xml

rb711e1d	r574b0ea
11	11	running at <emphasis>least</emphasis> a 2.6.2 kernel. The reasons for this high
12	12	requirement is the use of NPTL, but more importantly the use of udev. Udev
13		creates devices dynamically by reading from the ~~sysfs~~ file system. Only very
	13	creates devices dynamically by reading from the <systemitem class="filesystem">sysfs</systemitem> file system. Only very
14	14	recently has support for this file system been implemented in most of the kernel
15	15	drivers, however. We must be sure that all the critical system devices get

chapter05/kernel-headers.xml

rb711e1d	r574b0ea
42	42	<screen><userinput>make include/linux/version.h</userinput></screen>
43	43
44		<para>Create the platform-specific <filename>include/asm</filename>
	44	<para>Create the platform-specific <filename class="symlink">include/asm</filename>
45	45	symlink:</para>
46	46

chapter05/linux-libc-headers.xml

rb711e1d	r574b0ea
26	26
27	27	<para>For years it has been common practice to use so-called <quote>raw</quote>
28		kernel headers (straight from a kernel tarball) in ~~/usr/include~~, but over the
	28	kernel headers (straight from a kernel tarball) in <filename class="directory">/usr/include</filename>, but over the
29	29	last few years, the kernel developers have taken a strong stance that such
30	30	things should not be done. Thus was born the linux-libc-headers project,

chapter05/ncurses.xml

-              rb711e1d
+              r574b0ea
 <variablelist>
 <varlistentry>
 <term><userinput>--without-ada</userinput></term>
+<term><parameter>--without-ada</parameter></term>
 <listitem><para>This tells Ncurses not
 to build its Ada bindings, even if an Ada compiler is installed on the host.
 …
 <varlistentry>
 <term><userinput>--enable-overwrite</userinput></term>
+<term><parameter>--enable-overwrite</parameter></term>
 <listitem><para>This tells Ncurses to install its header files into
 <filename class="directory">/tools/include</filename> instead of

chapter05/patch.xml

rb711e1d	r574b0ea
29	29
30	30	<para>Prepare Patch for compilation (the preprocessor flag
31		<~~emphasis>-D_GNU_SOURCE</emphasis~~> is only needed on the PowerPC platform, on
	31	<parameter>-D_GNU_SOURCE</parameter> is only needed on the PowerPC platform, on
32	32	other architectures you can leave it out):</para>
33	33

chapter05/perl.xml

rb711e1d	r574b0ea
41	41	<variablelist>
42	42	<varlistentry>
43		<term><~~userinput>-Dstatic_ext='IO Fcntl POSIX'</userinput~~></term>
	43	<term><parameter>-Dstatic_ext='IO Fcntl POSIX'</parameter></term>
44	44	<listitem><para>This tells
45	45	Perl to build the minimum set of static extensions needed for installing and

chapter05/stripping.xml

rb711e1d	r574b0ea
21	21
22	22	<para>Take care <emphasis>not</emphasis> to use
23		<~~emphasis>--strip-unneeded</emphasis~~> on the libraries -- the static ones
	23	<parameter>--strip-unneeded</parameter> on the libraries -- the static ones
24	24	would be destroyed and you would have to build the three toolchain packages
25	25	all over again.</para>

chapter05/tcl.xml

-              rb711e1d
+              r574b0ea
 to experience failures under certain host conditions that are not fully
 understood. Therefore, test suite failures here are not surprising, and are not
 considered critical. The <emphasis>TZ=UTC</emphasis> parameter sets the time
+considered critical. The <parameter>TZ=UTC</parameter> parameter sets the time
 zone to Coordinated Universal Time (UTC) also known as Greenwich Mean Time
 (GMT), but only for the duration of the test suite run. This ensures the clock
 …
 <warning><para><emphasis>Do not remove</emphasis> the
 <filename>tcl&tcl-version;</filename> source directory yet, as the next package
+<filename class="directory">tcl&tcl-version;</filename> source directory yet, as the next package
 will need its internal headers.</para></warning>

chapter05/toolchaintechnotes.xml

-              rb711e1d
+              r574b0ea
 many folks the target triplet will probably be
 <emphasis>i686-pc-linux-gnu</emphasis>. A simple way to determine your target
 triplet is to run the <filename>config.guess</filename> script that comes with
+triplet is to run the <command>config.guess</command> script that comes with
 the source for many packages. Unpack the Binutils sources and run the script:
 <userinput>./config.guess</userinput> and note the output.</para>
 …
 <emphasis>dynamic linker</emphasis>, often also referred to as the
 <emphasis>dynamic loader</emphasis>, not to be confused with the standard linker
 <emphasis>ld</emphasis> that is part of Binutils. The dynamic linker is provided
+<command>ld</command> that is part of Binutils. The dynamic linker is provided
 by Glibc and has the job of finding and loading the shared libraries needed by a
 program, preparing the program to run and then running it. For most folks the
 name of the dynamic linker will be <emphasis>ld-linux.so.2</emphasis>. On
+name of the dynamic linker will be <filename>ld-linux.so.2</filename>. On
 platforms that are less prevalent, the name might be
 <emphasis>ld.so.1</emphasis> and newer 64 bit platforms might even have
+<filename>ld.so.1</filename> and newer 64 bit platforms might even have
 something completely different. You should be able to determine the name
 of your platform's dynamic linker by looking in the
 …
 <listitem><para>Careful manipulation of <command>gcc</command>'s
 <emphasis>specs</emphasis> file to tell the compiler which target dynamic
+<filename>specs</filename> file to tell the compiler which target dynamic
 linker will be used.</para></listitem>
 </itemizedlist>
 …
 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 <command>ld</command> by passing it the <emphasis>--verbose</emphasis>
+from <command>ld</command> by passing it the <parameter>--verbose</parameter>
 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 <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&gt;&amp;1 | grep succeeded</command>
+passing the <parameter>--verbose</parameter> switch to the linker. For example:
+<userinput>gcc dummy.c -Wl,--verbose 2&gt;&amp;1 | grep succeeded</userinput>
 will show you all the files successfully opened during the linking.</para>
 …
 <command>./configure</command> you'll see, for example:</para>
 <blockquote><screen>checking what assembler to use... /tools/i686-pc-linux-gnu/bin/as
 checking what linker to use... /tools/i686-pc-linux-gnu/bin/ld</screen></blockquote>
+<blockquote><screen><computeroutput>checking what assembler to use... /tools/i686-pc-linux-gnu/bin/as
+checking what linker to use... /tools/i686-pc-linux-gnu/bin/ld</computeroutput></screen></blockquote>
 <para>This is important for the reasons mentioned above. It also demonstrates
 …
 itself, the same search paths are not necessarily used. You can find out which
 standard linker <command>gcc</command> will use by running:
 <command>gcc -print-prog-name=ld</command>.
+<userinput>gcc -print-prog-name=ld</userinput>.
 Detailed information can be obtained from <command>gcc</command> by passing
 it the <emphasis>-v</emphasis> flag while compiling a dummy program. For
 example: <command>gcc -v dummy.c</command> will show you detailed
+it the <parameter>-v</parameter> flag while compiling a dummy program. For
+example: <userinput>gcc -v dummy.c</userinput> will show you detailed
 information about the preprocessor, compilation and assembly stages, including
 <command>gcc</command>'s include search paths and their order.</para>
 …
 <filename class="directory">glibc-build</filename> directory for all the
 important details. You'll note some interesting items like the use of
 <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
+<parameter>CC="gcc -B/tools/bin/"</parameter> to control which binary tools are
+used, and also the use of the <parameter>-nostdinc</parameter> and
+<parameter>-isystem</parameter> flags to control the compiler's include search
 path. These items help to highlight an important aspect of the Glibc package:
 it is very self-sufficient in terms of its build machinery and generally does
 …
 <para>After the Glibc installation, we make some adjustments to ensure that
 searching and linking take place only within our <filename>/tools</filename>
+searching and linking take place only within our <filename class="directory">/tools</filename>
 prefix. We install an adjusted <command>ld</command>, which has a hard-wired
 search path limited to <filename class="directory">/tools/lib</filename>. Then
 …
 hard-wired path to a dynamic linker is embedded into every ELF shared
 executable. You can inspect this by running:
 <command>readelf -l &lt;name of binary&gt; | grep interpreter</command>.
+<userinput>readelf -l &lt;name of binary&gt; | grep interpreter</userinput>.
 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
 …
 <para>During the second pass of Binutils, we are able to utilize the
 <emphasis>--with-lib-path</emphasis> configure switch to control
+<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

chapter05/udev.xml

-              rb711e1d
+              r574b0ea
 by applying the following patch:</para>
+<screen><userinput>patch -Np1 -i ../udev-&udev-version;-config-2.patch
+</userinput></screen>
+<screen><userinput>patch -Np1 -i ../udev-&udev-version;-config-2.patch</userinput></screen>
 <para>The udevstart program hardcodes the path to the udev program in itself,

chapter05/util-linux.xml

rb711e1d	r574b0ea
34	34
35	35	<para>Util-linux doesn't use the freshly installed headers and libraries
36		from the ~~/tools~~ directory. This is fixed by altering the configure
	36	from the <filename class="directory">/tools</filename> directory. This is fixed by altering the configure
37	37	script:</para>
38	38

stylesheets/lfs.css

rb711e1d	r574b0ea
234	234
235	235	pre.screen {
	236	color: #000;
236	237	background-color: #e9e9e9;
237	238	border: 1px solid #050505;

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

Context Navigation

Changeset 574b0ea

Legend:

Download in other formats: