diff options
Diffstat (limited to 'chapter05')
| -rw-r--r-- | chapter05/bash.xml | 2 | ||||
| -rw-r--r-- | chapter05/binutils-pass1.xml | 6 | ||||
| -rw-r--r-- | chapter05/bzip2.xml | 2 | ||||
| -rw-r--r-- | chapter05/chapter05.xml | 85 | ||||
| -rw-r--r-- | chapter05/gcc-pass1.xml | 10 | ||||
| -rw-r--r-- | chapter05/gcc-pass2.xml | 8 | ||||
| -rw-r--r-- | chapter05/glibc.xml | 8 | ||||
| -rw-r--r-- | chapter05/grep.xml | 2 | ||||
| -rw-r--r-- | chapter05/kernelheaders.xml | 2 | ||||
| -rw-r--r-- | chapter05/patch.xml | 2 |
10 files changed, 63 insertions, 64 deletions
diff --git a/chapter05/bash.xml b/chapter05/bash.xml index 0772e21f0..05e62ab97 100644 --- a/chapter05/bash.xml +++ b/chapter05/bash.xml @@ -36,7 +36,7 @@ suite anyway, the following command will do so:</para> <screen><userinput>make install</userinput></screen> -<para>And make a link for the programs that use <userinput>sh</userinput> +<para>And make a link for the programs that use <command>sh</command> for a shell:</para> <screen><userinput>ln -s bash /tools/bin/sh</userinput></screen> diff --git a/chapter05/binutils-pass1.xml b/chapter05/binutils-pass1.xml index a98f498c4..34883a596 100644 --- a/chapter05/binutils-pass1.xml +++ b/chapter05/binutils-pass1.xml @@ -66,9 +66,9 @@ problem.</para></listitem> <listitem><para><userinput>LDFLAGS="-all-static"</userinput>: This tells the linker that all the Binutils programs should be linked statically. However, -strictly speaking, <userinput>"-all-static"</userinput> is first passed to the -<emphasis>libtool</emphasis> program which then passes -<userinput>"-static"</userinput> on to the linker.</para></listitem> +strictly speaking, <emphasis>"-all-static"</emphasis> is first passed to the +<command>libtool</command> program which then passes +<emphasis>"-static"</emphasis> on to the linker.</para></listitem> </itemizedlist> <para>Compilation is now complete. This is the point where we would normally diff --git a/chapter05/bzip2.xml b/chapter05/bzip2.xml index d11c8e531..72cc0310c 100644 --- a/chapter05/bzip2.xml +++ b/chapter05/bzip2.xml @@ -13,7 +13,7 @@ <sect2> <title>Installation of Bzip2</title> -<para>The Bzip2 package doesn't contain a <userinput>configure</userinput> +<para>The Bzip2 package doesn't contain a <command>configure</command> script. Compile and install it with a straightforward:</para> <screen><userinput>make PREFIX=/tools install</userinput></screen> diff --git a/chapter05/chapter05.xml b/chapter05/chapter05.xml index 53139ae54..0349addd0 100644 --- a/chapter05/chapter05.xml +++ b/chapter05/chapter05.xml @@ -23,7 +23,7 @@ Since the packages compiled here are merely temporary, we don't want them to pollute the soon-to-be LFS system.</para> <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 directory of a package before issuing its build commands.</para> @@ -100,7 +100,7 @@ something completely different. You should be able to determine the name of your platform's dynamic linker by looking in the <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 <name of binary> | grep interpreter'</userinput> +<userinput>readelf -l <name of binary> | 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 tree.</para> @@ -118,14 +118,14 @@ into the same prefix work in cooperation and thus utilize a little GNU path to ensure programs are linked only against libraries we 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> </itemizedlist> <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 of such breakage might not show up until near the end of the build of a whole @@ -137,43 +137,43 @@ much time is wasted.</para> <filename class="directory">/tools/$TARGET_TRIPLET/bin</filename>. In reality, 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>&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>&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 checking what linker to use... /tools/i686-pc-linux-gnu/bin/ld</screen></blockquote> <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 path. These items help to highlight an important aspect of the Glibc package: @@ -182,18 +182,17 @@ not rely on toolchain defaults.</para> <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 <name of binary> | 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 <name of binary> | 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 Specs patch for the second pass of GCC. Failure to do so will result in the GCC @@ -203,7 +202,7 @@ would defeat our goal of getting away from the host.</para> <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">/tools</filename> and all is well.</para> @@ -213,7 +212,7 @@ first major package we install is Glibc, due to its self-sufficient nature that we mentioned above. Once this Glibc is installed into <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> <title>Notes on static linking</title> @@ -288,7 +287,7 @@ partition:</para> <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> @@ -349,8 +348,8 @@ user command:</para> <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> @@ -360,7 +359,7 @@ start a <emphasis>login</emphasis> shell.</para> <?dbhtml filename="settingenvironment.html" dir="chapter05"?> <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> @@ -372,7 +371,7 @@ exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash the initial shell is a <emphasis>login</emphasis> shell which reads the <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 potentially hazardous environment variables from the host system leak into our @@ -393,15 +392,15 @@ PATH=/tools/bin:/bin:/usr/bin export LFS LC_ALL PATH <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> <para>Setting the user file-creation mask to 022 ensures that newly created @@ -519,8 +518,8 @@ appears as the prefix of our dynamic linker. If you did not receive the output as shown above, or received no output at all, then something is seriously wrong. 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 is correct. You can check this by running <userinput>echo $PATH</userinput> and @@ -587,7 +586,7 @@ that it doesn't recognize their file format. Most of them are scripts instead of binaries.</para> <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> <para>To save another couple of megabytes, you can throw away all the diff --git a/chapter05/gcc-pass1.xml b/chapter05/gcc-pass1.xml index ed1d8a27e..08822cbf0 100644 --- a/chapter05/gcc-pass1.xml +++ b/chapter05/gcc-pass1.xml @@ -42,7 +42,7 @@ cd ../gcc-build</userinput></screen> <itemizedlist> <listitem><para><userinput>--with-local-prefix=/tools</userinput>: The purpose of this switch is to remove <filename>/usr/local/include</filename> -from <userinput>gcc</userinput>'s include search path. This is not absolutely +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 system, thus making this a sensible thing to do.</para></listitem> @@ -51,8 +51,8 @@ seem counter-intuitive at first. But using it allows the building of <filename>libgcc_s.so.1</filename> and <filename>libgcc_eh.a</filename>, and 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 <userinput>gcc</userinput> binaries will still be linked -statically, as this is controlled by the <userinput>-static</userinput> +Note that the <command>gcc</command> binaries will still be linked +statically, as this is controlled by the <command>-static</command> value of BOOT_LDFLAGS further on.</para></listitem> <listitem><para><userinput>--enable-languages=c</userinput>: This option @@ -92,10 +92,10 @@ the second pass.</para> <para>As a finishing touch we'll create the <filename class="symlink">/tools/bin/cc</filename> symlink. Many programs and -scripts run <userinput>cc</userinput> instead of <userinput>gcc</userinput>, +scripts run <command>cc</command> instead of <command>gcc</command>, a thing meant to keep programs generic and therefore usable on all kinds of Unix systems. Not everybody has the GNU C compiler installed. Simply running -<userinput>cc</userinput> leaves the system administrator free to decide what +<command>cc</command> leaves the system administrator free to decide what C compiler to install, as long as there's a symlink pointing to it:</para> <screen><userinput>ln -s gcc /tools/bin/cc</userinput></screen> diff --git a/chapter05/gcc-pass2.xml b/chapter05/gcc-pass2.xml index 34f8f18d8..982c267d6 100644 --- a/chapter05/gcc-pass2.xml +++ b/chapter05/gcc-pass2.xml @@ -112,7 +112,7 @@ needed to ensure that both C and C++ compilers are built.</para></listitem> <screen><userinput>make</userinput></screen> -<para>There is no need to use the <userinput>bootstrap</userinput> target now, +<para>There is no need to use the <emphasis>bootstrap</emphasis> 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> @@ -123,7 +123,7 @@ so:</para> <screen><userinput>make -k check</userinput></screen> -<para>The <userinput>-k</userinput> flag is used to make the test suite run +<para>The <emphasis>-k</emphasis> 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 a summary of the test suite results, run this:</para> @@ -142,12 +142,12 @@ current GCC-&gcc-version; should look on i686-pc-linux-gnu, see * 24 XPASS's for libstdc++</screen> <para>The unexpected pass for g++ is due to the use of -<userinput>--enable-__cxa_atexit</userinput>. Apparently not all platforms +<emphasis>--enable-__cxa_atexit</emphasis>. Apparently not all platforms supported by GCC have support for "__cxa_atexit" in their C libraries, so this test is not always expected to pass.</para> <para>The 24 unexpected passes for libstdc++ are due to the use of -<userinput>--enable-clocale=gnu</userinput>, which is the correct choice on +<emphasis>--enable-clocale=gnu</emphasis>, which is the correct choice on Glibc-based systems of versions 2.2.5 and above. The underlying locale support in the GNU C library is superior to that of the otherwise selected "generic" model (which may be applicable if for instance you were using Newlibc, Sun-libc diff --git a/chapter05/glibc.xml b/chapter05/glibc.xml index e8c2e8e91..5b5f1d77e 100644 --- a/chapter05/glibc.xml +++ b/chapter05/glibc.xml @@ -53,7 +53,7 @@ regard to what kernel headers and Binutils programs get used during the Glibc build.</para></listitem> <listitem><para><userinput>--without-gd</userinput>: This switch ensures -that we don't build the <userinput>memusagestat</userinput> program, which +that we don't build the <command>memusagestat</command> program, which strangely enough insists on linking against the host's libraries (libgd, libpng, libz, and so forth).</para></listitem> @@ -122,9 +122,9 @@ ultimately end up using so that is the one we would really like to see pass. But please keep in mind, even in <xref linkend="chapter06"/> some failures could still occur -- the <emphasis>math</emphasis> tests for example. When experiencing a failure, make a note of it, then -continue by reissuing the <userinput>make check</userinput>. The test suite +continue by reissuing the <command>make check</command>. The test suite should pick up where it left off and continue on. You can circumvent this -stop-start sequence by issuing a <userinput>make -k check</userinput>. But if +stop-start sequence by issuing a <command>make -k check</command>. But if you do that, be sure to log the output so that you can later peruse the log file and examine the total number of failures.</para> @@ -156,7 +156,7 @@ command will do so:</para> <para>An alternative to running the previous command is to install only those locales which you need or want. This can be achieved by using the -<userinput>localedef</userinput> command. Information on this can be found in +<command>localedef</command> command. Information on this can be found in the <filename>INSTALL</filename> file in the Glibc source. However, there are a number of locales that are essential for the tests of future packages to pass, in particular, the <emphasis>libstdc++</emphasis> tests from GCC. The diff --git a/chapter05/grep.xml b/chapter05/grep.xml index bb349ea6c..e05a15341 100644 --- a/chapter05/grep.xml +++ b/chapter05/grep.xml @@ -22,7 +22,7 @@ <itemizedlist> <listitem><para><userinput>--disable-perl-regexp</userinput>: This makes sure -that <userinput>grep</userinput> does not get linked against a PCRE library +that <command>grep</command> does not get linked against a PCRE library that may be present on the host and would not be available once we enter the chroot environment.</para></listitem> <listitem><para><userinput>--with-included-regex</userinput>: This ensures that diff --git a/chapter05/kernelheaders.xml b/chapter05/kernelheaders.xml index e535ff5d5..adc7a668d 100644 --- a/chapter05/kernelheaders.xml +++ b/chapter05/kernelheaders.xml @@ -12,7 +12,7 @@ <para>As some packages need to refer to the kernel header files, we're going to unpack the kernel archive now, set it up, and copy the required files to a -place where <userinput>gcc</userinput> can later find them.</para> +place where <command>gcc</command> can later find them.</para> <para>Prepare for the header installation with:</para> diff --git a/chapter05/patch.xml b/chapter05/patch.xml index 4f9e4647d..ab72274aa 100644 --- a/chapter05/patch.xml +++ b/chapter05/patch.xml @@ -17,7 +17,7 @@ <screen><userinput>CPPFLAGS=-D_GNU_SOURCE ./configure --prefix=/tools</userinput></screen> -<para>The preprocessor flag <userinput>-D_GNU_SOURCE</userinput> is only needed +<para>The preprocessor flag <emphasis>-D_GNU_SOURCE</emphasis> is only needed on the PowerPC platform. On other architectures you can leave it out.</para> <para>Compile the program:</para> |