Context Navigation

-              re421d2e
+              rede9b9b
 <listitem><para>man-pages-1.66</para></listitem>
 <listitem><para>ncurses-5.4</para></listitem>
+</itemizedlist></listitem>
+</itemizedlist>
+</listitem>
+<listitem><para>Added:</para>
+<itemizedlist>
+<listitem><para>make_devices-1.2</para></listitem>
+</itemizedlist>
+</listitem>
+<listitem><para>Removed:</para>
+<itemizedlist>
+<listitem><para>MAKEDEV-1.7</para></listitem>
+<listitem><para>ncurses-5.3-etip-2.patch</para></listitem>
+</itemizedlist>
+</listitem>
 <listitem><para>February 23rd, 2004 [alex]: Chapters 6 + 9 : Cleaned up the

chapter05/binutils-pass1.xml

-              re421d2e
+              rede9b9b
 assembler to determine which of their own features to enable.</para>
 <para>This package is known to behave badly when you have changed its default
 optimization flags (including the -march and -mcpu options). Therefore, if
+you have defined any environment variables that override default
+optimizations, such as CFLAGS and CXXFLAGS, we recommend unsetting or
 modifying them when building Binutils.</para>
+<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
+environment variables that override default optimizations, such as CFLAGS and
+CXXFLAGS, we recommend unsetting them when building Binutils.</para>
 <para>The Binutils documentation recommends building Binutils outside of the
 …
 <note><para>If you want the SBU values listed in the rest of the book to be of
+any use, you will have to measure the time it takes to build this package. To
+achieve this easily, you could do something like:
+<userinput>time { ./configure ... &amp;&amp; ... &amp;&amp; ... &amp;&amp; make install; }</userinput>.</para></note>
+any use, you will have to measure the time it takes to build this package --
+from the configuration upto and including the first install. To achieve this
+easily, you could wrap the four commands in a <command>time</command> command
+like this: <userinput>time { ./configure ... &amp;&amp; ... &amp;&amp; ...
+&amp;&amp; make install; }</userinput>.</para></note>
 <para>Now prepare Binutils for compilation:</para>
 …
 <listitem><para><userinput>LDFLAGS="-all-static"</userinput>: This tells the
 linker that all the Binutils programs should be linked statically. However,
 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>
+strictly speaking, <emphasis>"-all-static"</emphasis> is passed to the
+<command>libtool</command> program, which then passes
+<emphasis>"-static"</emphasis> to the linker.</para></listitem>
 </itemizedlist>
+<para>Compilation is now complete. This is the point where we would normally
+run the test suite. But as discussed earlier, we don't recommend running the
+test suites for the temporary tools here in this chapter. However, even if we
+still wanted to run the Binutils test suite, we're unable do so at this early
+stage because the test suite framework is not yet in place. Not only that, the
+programs from this first pass will soon be overwritten by those installed in
+the second pass.</para>
+<para>Compilation is complete. Normally we would now run the test suite, but
+at this early stage the test suite framework (Tcl, Expect and DejaGnu) is not
+yet in place. And there would be little point in running the tests anyhow,
+since the programs from this first pass will soon be replaced by those from the
+second.</para>
 <para>And install the package:</para>
 …
 <itemizedlist>
 <listitem><para><userinput>-C ld clean</userinput>: This tells the make program
 to remove all the compiled files, but only in the <filename>ld</filename>
 subdirectory.</para></listitem>
+to remove all the compiled files in the <filename
+class="directory">ld</filename> subdirectory.</para></listitem>
 <listitem><para><userinput>-C ld LDFLAGS="-all-static" LIB_PATH=/tools/lib</userinput>:
+This option rebuilds everything in the <filename>ld</filename> subdirectory.
+Specifying the LIB_PATH makefile variable on the command line allows us to
+override the default value and have it point to our temporary tools location.
+The value of this variable specifies the linker's default library search path.
+You'll see how this preparation is used later on in the
 chapter.</para></listitem>
+<listitem><para><userinput>-C ld LDFLAGS="-all-static"
+LIB_PATH=/tools/lib</userinput>: This option rebuilds everything in the
+<filename class="directory">ld</filename> subdirectory. Specifying the LIB_PATH
+makefile variable on the command line allows us to override the default value
+and have it point to our temporary tools location. The value of this variable
+specifies the linker's default library search path. You will see how this
+preparation is used later on in the chapter.</para></listitem>
 </itemizedlist>

chapter05/binutils-pass2.xml

-              re421d2e
+              rede9b9b
 &aa-binutils-down;
 &aa-binutils-dep;
 <sect2><title>&nbsp;</title><para>&nbsp;</para></sect2>
 …
 <itemizedlist>
 <listitem><para><userinput>--with-lib-path=/tools/lib</userinput>: This tells
+the configure script to specify the default library search path. We don't want
+the library search path to contain library directories from the host
+system.</para></listitem>
+the configure script to specify the library search path during the compilation
+of Binutils, resulting in <emphasis>/tools/lib</emphasis> to be passed to the
+linker. This prevents the linker from searching through library directories on
+the host.</para></listitem>
 </itemizedlist>
 …
 <para>Compilation is now complete. As discussed earlier, we don't recommend
 running the test suites for the temporary tools here in this chapter. If you
+still want to run the Binutils test suite anyway, the following command will
 do so:</para>
+running the test suites for the temporary tools here in this chapter. If
+nevertheless you want to run the Binutils test suite, the following command
+will do so:</para>
 <screen><userinput>make check</userinput></screen>
 <para>There should be no unexpected failures here, expected failures are fine.
 Unfortunately, there is no easy way to view the test results summary like
+there was for the previous GCC package. However, if a failure occurs here, it
 should be easy to spot. The output shown will contain something like:</para>
+Unfortunately, there is no easy way to view the test results summary like there
+was for the GCC package. However, if a failure occurs here, it should be easy
+to spot. The output shown will contain something like:</para>
 <blockquote><screen>make[1]: *** [check-binutils] Error 2</screen></blockquote>

chapter05/chapter05.xml

-              re421d2e
+              rede9b9b
 <para>If everything is working correctly, there should be no errors, and the
+output of the last command will be:</para>
+output of the last command will be (allowing for platform specific differences
+in dynamic linker name):</para>
 <blockquote><screen>[Requesting program interpreter: /tools/lib/ld-linux.so.2]</screen></blockquote>
+<para>(Of course allowing for platform specific differences in dynamic linker
+name). Note especially that <filename class="directory">/tools/lib</filename>
+appears as the prefix of our dynamic linker. If you did not receive the output
+<para>Note especially that <filename class="directory">/tools/lib</filename>
+appears as the prefix of our dynamic linker.</para>
+<para>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

chapter05/coreutils.xml

-              re421d2e
+              rede9b9b
 <title>Installation of Coreutils</title>
 <para>Coreutils has an issue when compiled against Glibc-&glibc-version;.
 Without the patch below, some of the Coreutils utilities
 (<command>head</command>, <command>tail</command>, <command>sort</command>,
 and others) will reject their traditional syntax which has been in use for
+<para>This package has an issue when compiled against Glibc-&glibc-version;.
+Without the patch below, some of the Coreutils utilities (such as
+(<command>head</command>, <command>tail</command> and <command>sort</command>)
+will reject their traditional syntax, a syntax that has been in use for
 approximately 30 years. This old syntax is so pervasive that compatibility
 should be preserved until the many places where it is used can be updated.
+More details on this are provided in the comments inside the patch itself. Use
 of this patch is by no means compulsory, but not using it means you'll have to
 deal with the consequences yourself: patch the many packages that use the old
 syntax. Therefore, better apply the patch:</para>
+should be preserved until the many places where it is used can be updated. More
+details on this are provided in the comments inside the patch itself. Use of
+this patch is by no means compulsory, but not using it means you'll have to
+deal with the consequences yourself: patch the many packages that still use the
+old syntax. Therefore, better apply the patch:</para>
 <screen><userinput>patch -Np1 -i ../&coreutils-posixver-patch;</userinput></screen>

chapter05/expect.xml

-              re421d2e
+              rede9b9b
 <title>Installation of Expect</title>
+<para>First apply a patch:</para>
+<para>First fix a bug that can result in bogus failures during the GCC test
+suite run:</para>
 <screen><userinput>patch -Np1 -i ../&expect-patch;</userinput></screen>
-<para>This fixes a bug in Expect that can result in bogus failures during the
-GCC test suite run.</para>
 <para>Now prepare Expect for compilation:</para>
 …
 <itemizedlist>
 <listitem><para><userinput>SCRIPTS=""</userinput>: This prevents installation of
 the supplementary expect scripts which are not needed.</para></listitem>
+<listitem><para><userinput>SCRIPTS=""</userinput>: This prevents installation
+of the supplementary expect scripts which are not needed.</para></listitem>
 </itemizedlist>

chapter05/gcc-pass1.xml

-              re421d2e
+              rede9b9b
 <title>Installation of GCC</title>
 <para>Unpack only the GCC-core tarball, as we won't be needing a C++ compiler
 for the moment.</para>
+<para>Unpack only the GCC-core tarball, as we won't be needing the C++ compiler
+nor the test suite at the moment.</para>
 <para>This package is known to behave badly when you have changed its
+default optimization flags (including the -march and -mcpu options).
+Therefore, if you have defined any environment variables that override
+default optimizations, such as CFLAGS and CXXFLAGS, we recommend unsetting
 or modifying them when building GCC.</para>
+<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
+environment variables that override default optimizations, such as CFLAGS and
+CXXFLAGS, we recommend unsetting them when building GCC.</para>
 <para>The GCC documentation recommends building GCC outside of the source
 …
 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 <command>-static</command>
 value of BOOT_LDFLAGS further on.</para></listitem>
+statically, as this is controlled by the <emphasis>-static</emphasis>
+value of BOOT_LDFLAGS in the next step.</para></listitem>
 <listitem><para><userinput>--enable-languages=c</userinput>: This option
 …
 </itemizedlist>
+<para>Compilation is now complete. This is the point where we would normally
+run the test suite. But as discussed earlier, we don't recommend running the
+test suites for the temporary tools here in this chapter. However, even if we
+still wanted to run the GCC test suite, we're unable do so at this early stage
+because the test suite framework is not yet in place. Not only that, the
+programs from this first pass will soon be overwritten by those installed in
+the second pass.</para>
+<para>Compilation is now complete, and at this point we would normally run the
+test suite. But, as mentioned before, the test suite framework is not in place
+yet. And there would be little point in running the tests anyhow, since the
+programs from this first pass will soon be replaced.</para>
 <para>And install the package:</para>
 …
 <screen><userinput>make install</userinput></screen>
+<para>As a finishing touch we'll create the <filename
+class="symlink">/tools/bin/cc</filename> symlink. Many programs and
+scripts run <command>cc</command> instead of <command>gcc</command>,
+<para>As a finishing touch we'll create a symlink. Many programs and 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

chapter05/gcc-pass2.xml

-              re421d2e
+              rede9b9b
 <title>Re-installation of GCC</title>
 <para>The tools required to test GCC and Binutils are installed now (Tcl, Expect
+and DejaGnu). We can continue on rebuilding GCC and Binutils, link them against
 the new Glibc, and test them properly (if performing the test suites in this
+chapter). One thing to note, however, is that these test suites are highly
+dependent on properly functioning pseudo terminals (PTYs) which are provided by
 your host distribution. These days, PTYs are most commonly implemented via the
+<para>The tools required to test GCC and Binutils are installed now: Tcl,
+Expect and DejaGnu. Therefore we can now rebuild GCC and Binutils, linking
+them against the new Glibc, and test them properly (if running the test suites
+in this chapter). One thing to note, however, is that these test suites are
+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
 system is set up correctly in this regard by performing a simple test:</para>
 …
 <screen><userinput>expect -c "spawn ls"</userinput></screen>
 <para>If you receive the message:</para>
+<para>The response might be:</para>
 <blockquote><screen>The system has no more ptys.  Ask your system administrator to create more.</screen></blockquote>
 <para>Your host distribution is not set up for proper PTY operation. In this
+case there is no point in running the test suites for GCC and Binutils until
+you are able to resolve the issue. You can consult the LFS Wiki at
 <ulink url="&wiki-root;"/> for more information on how to get PTYs
+<para>If you receive the above message, your host doesn't have its PTYs set up
+properly. In this case there is no point in running the test suites for GCC
+and Binutils until you are able to resolve the issue. You can consult the LFS
+Wiki at <ulink url="&wiki-root;"/> for more information on how to get PTYs
 working.</para>
 <para>This time we will build both the C and the C++ compilers, so you'll have
 to unpack all three GCC tarballs (-core, -g++, and -testsuite) in one and the
+same working directory. They will all unfold into a single
 <filename>&gcc-dir;/</filename> subdirectory.</para>
+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-dir;/</filename> subdirectory.</para>
 <para>First correct one problem and make an essential adjustment:</para>
+<para>First correct a problem and make an essential adjustment:</para>
 <screen><userinput>patch -Np1 -i ../&gcc-nofixincludes-patch;
 …
 system.</para>
 <para>The last patch changes GCC's default location of the dynamic linker
+<para>The second patch changes GCC's default location of the dynamic linker
 (typically <filename>ld-linux.so.2</filename>). It also removes
 <filename class="directory">/usr/include</filename> from GCC's include search
 …
 <itemizedlist>
+<listitem><para><userinput>--enable-clocale=gnu</userinput>: This option
+ensures the correct locale model is selected for the C++ libraries under all
+circumstances. If the configure script finds the <emphasis>de_DE</emphasis>
+locale installed, it will select the correct <emphasis>gnu</emphasis> locale
+model. However, people who don't install the <emphasis>de_DE</emphasis> locale
+would run the risk of building ABI incompatible C++ libraries due to the wrong
+<emphasis>generic</emphasis> locale model being selected.</para></listitem>
 <listitem><para><userinput>--enable-threads=posix</userinput>: This enables
 C++ exception handling for multi-threaded code.</para></listitem>
 …
 distributions.</para></listitem>
+<listitem><para><userinput>--enable-clocale=gnu</userinput>: This option ensures
+the correct locale model is selected for the C++ libraries under all
+circumstances. If the configure script finds the <emphasis>de_DE</emphasis>
+locale installed, it will select the correct model of <emphasis>gnu</emphasis>.
+However, people who don't install the <emphasis>de_DE</emphasis> locale, run the
+risk of building ABI incompatible C++ libraries due to the wrong locale model of
+<emphasis>generic</emphasis> being selected.</para></listitem>
+<listitem><para><userinput>--enable-languages=c,c++</userinput>: This option is
+needed to ensure that both C and C++ compilers are built.</para></listitem>
+<listitem><para><userinput>--enable-languages=c,c++</userinput>: This option
+ensures that both the C and C++ compilers are built.</para></listitem>
 </itemizedlist>
 …
 version of the GCC sources we used earlier.</para>
 <para>Compilation is now complete. As discussed earlier, we don't recommend
+<para>Compilation is now complete. As mentioned earlier, we don't recommend
 running the test suites for the temporary tools here in this chapter. If you
 still want to run the GCC test suite anyway, the following command will do
 …
 <para>The 24 unexpected passes for libstdc++ are due to the use of
+<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
+or whatever libc). The libstdc++ test suite is apparently expecting the
+"generic" model, hence those tests are not always expected to pass.</para>
+<emphasis>--enable-clocale=gnu</emphasis>. This option, which is the correct
+choice on Glibc-based systems of versions 2.2.5 and above, enables in the GNU C
+library a locale support that is superior to the otherwise selected
+<emphasis>generic</emphasis> model (which may be applicable if for instance you
+were using Newlibc, Sun-libc or whatever other libc). The libstdc++ test suite
+is apparently expecting the <emphasis>generic</emphasis> model, hence those
+tests are not always expected to pass.</para>
 <para>Unexpected failures often cannot be avoided. The GCC developers are
+usually aware of them but haven't yet gotten around to fixing them. In short,
 unless your results are vastly different from those at the above URL, it is safe
 to continue on.</para>
+<para>Having a few unexpected failures often cannot be avoided. The GCC
+developers are usually aware of these, but haven't yet gotten around to fixing
+them. In short, unless your results are vastly different from those at the
+above URL, it is safe to continue.</para>
 <para>And finally install the package:</para>
 …
 <note><para>At this point it is strongly recommended to repeat the sanity check
 we performed earlier in this chapter. Refer back to
 <xref linkend="ch-tools-adjusting"/> and repeat the check. If the results are
+wrong, then most likely you forgot to apply the above mentioned GCC Specs
 patch.</para></note>
+<xref linkend="ch-tools-adjusting"/> and repeat the little test compilation. If
+the result is wrong, then most likely you forgot to apply the above mentioned
+GCC Specs patch.</para></note>
 </sect2>

chapter05/glibc.xml

-              re421d2e
+              rede9b9b
 <title>Installation of Glibc</title>
 <para>This package is known to behave badly when you have changed its
+default optimization flags (including the -march and -mcpu options).
+Therefore, if you have defined any environment variables that override
+default optimizations, such as CFLAGS and CXXFLAGS, we recommend unsetting
 them when building Glibc.</para>
+<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
+environment variables that override default optimizations, such as CFLAGS and
+CXXFLAGS, we recommend unsetting them when building Glibc.</para>
 <para>Basically, compiling Glibc in any other way than the book suggests
 …
 <listitem><para><userinput>--disable-profile</userinput>: This disables the
 building of the libraries with profiling information. Omit this option if you
 plan to do profiling.</para></listitem>
+plan to do profiling on the temporary tools.</para></listitem>
 <listitem><para><userinput>--enable-add-ons=linuxthreads</userinput>: This
 …
 *** Check the INSTALL file for required versions.</screen></blockquote>
 <para>The missing or incompatible <filename>msgfmt</filename> program is
+<para>The missing or incompatible <command>msgfmt</command> program is
 generally harmless, but it's believed it can sometimes cause problems when
 running the test suite.</para>
 …
 <screen><userinput>make</userinput></screen>
 <para>Compilation is now complete. As discussed earlier, we don't recommend
+<para>Compilation is now complete. As mentioned earlier, we don't recommend
 running the test suites for the temporary system here in this chapter. If you
 still want to run the Glibc test suite anyway, the following command will do
 …
 can be adversely affected by existing tools or environmental issues on the host
 system. Of course, these won't be a problem when we run the Glibc test suite
 inside the chroot environment of <xref linkend="chapter-building-system"/>. In general, the
+Glibc test suite is always expected to pass. However, as mentioned above, some
 failures are unavoidable in certain circumstances. Here is a list of the most
 common issues we are aware of:</para>
+inside the chroot environment of <xref linkend="chapter-building-system"/>. In
+general, the Glibc test suite is always expected to pass. However, as mentioned
+above, in certain circumstances some failures are unavoidable. Here is a list
+of the most common issues we are aware of:</para>
 <itemizedlist>
 …
 <para>In summary, don't worry too much if you see Glibc test suite failures
+here in this chapter. The Glibc in <xref linkend="chapter-building-system"/> is the one we'll
+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="chapter-building-system"/> 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 <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 <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>
+here in this chapter. The Glibc in <xref linkend="chapter-building-system"/> is
+the one we'll ultimately end up using, so that is the one we would really like
+to see pass the tests (but even there 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 <command>make
+check</command>. The test suite should pick up where it left off and continue.
+You can circumvent this 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>
 <para>Though it is a harmless message, the install stage of Glibc will
 complain about the absence of <filename>/tools/etc/ld.so.conf</filename>.
 Fix this annoying little warning with:</para>
+<para>Though it is a harmless message, the install stage of Glibc will at the
+end complain about the absence of <filename>/tools/etc/ld.so.conf</filename>.
+Prevent this confusing little warning with:</para>
 <screen><userinput>mkdir /tools/etc

chapter05/kernelheaders.xml

-              re421d2e
+              rede9b9b
 <para>This ensures that the kernel tree is absolutely clean. The kernel team
 recommends that this command be issued prior to <emphasis>each</emphasis> kernel
 compilation. You shouldn't rely on the source tree being clean after
+recommends that this command be issued prior to <emphasis>each</emphasis>
+kernel compilation. You shouldn't rely on the source tree being clean after
 untarring.</para>

chapter05/tcl.xml

-              re421d2e
+              rede9b9b
 <title>Installation of Tcl</title>
 <para>This package and the next two are only installed to be able to run the
 test suites for GCC and Binutils. Installing three packages just for testing
 purposes may seem like overkill, but it is very reassuring, if not essential,
+<para>This package and the next two are only installed to be able to run the
+test suites for GCC and Binutils. Installing three packages just for testing
+purposes may seem like overkill, but it is very reassuring, if not essential,
 to know that our most important tools are working properly. Even if you are
 not running the test suites here in this chapter as per our recommendation,
 these packages are still required for the test suites in the next
+these packages are still required for running the test suites in the next
 chapter.</para>

chapter06/chapter06.xml

-              re421d2e
+              rede9b9b
 <para>If everything is working correctly, there should be no errors, and the
+output of the last command will be:</para>
+output of the last command will be (allowing for platform specific differences
+in dynamic linker name):</para>
 <blockquote><screen>[Requesting program interpreter: /lib/ld-linux.so.2]</screen></blockquote>
+<para>(Of course allowing for platform specific differences in dynamic linker
+name). Note especially that <filename class="directory">/lib</filename> now
+appears as the prefix of our dynamic linker. If you did not receive the output
+<para>Note especially that <filename class="directory">/lib</filename> is now
+the prefix of our dynamic linker.</para>
+<para> 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

index.xml

-              re421d2e
+              rede9b9b
                         "/usr/share/docbook/docbookx.dtd" [
 <!ENTITY version "CVS-2004-02-24">
 <!ENTITY releasedate "February 24th, 2004">
+<!ENTITY version "CVS-2004-02-25">
+<!ENTITY releasedate "February 25th, 2004">
 <!ENTITY milestone "5.2">
 <!ENTITY nbsp " ">

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

Context Navigation

Changeset ede9b9b

Legend:

Download in other formats: