mirror of
https://git.linuxfromscratch.org/lfs.git
synced 2025-03-05 22:04:48 +00:00
Minor textual shuffles.
git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@3261 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689
This commit is contained in:
Alex Gronenwoud
parent
e421d2e1df
commit
ede9b9be0a
@ -17,7 +17,21 @@ first a summary, then a detailed log.</para>
|
||||
<listitem><para>less-382</para></listitem>
|
||||
<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
|
||||
Revision of chroot and Reboot sections.</para></listitem>
|
||||
|
||||
@ -17,11 +17,11 @@
|
||||
because both Glibc and GCC perform various tests on the available linker and
|
||||
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
|
||||
source directory in a dedicated build directory:</para>
|
||||
@ -30,9 +30,11 @@ source directory in a dedicated build directory:</para>
|
||||
cd ../binutils-build</userinput></screen>
|
||||
|
||||
<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 ... && ... && ... && 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 ... && ... && ...
|
||||
&& make install; }</userinput>.</para></note>
|
||||
|
||||
<para>Now prepare Binutils for compilation:</para>
|
||||
|
||||
@ -66,18 +68,16 @@ 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, <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>
|
||||
|
||||
@ -92,16 +92,16 @@ make -C ld LDFLAGS="-all-static" LIB_PATH=/tools/lib</userinput></screen>
|
||||
|
||||
<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>
|
||||
|
||||
<!-- HACK - Force some whitespace to appease tidy -->
|
||||
|
||||
@ -8,7 +8,6 @@
|
||||
&aa-binutils-down;
|
||||
&aa-binutils-dep;
|
||||
|
||||
|
||||
<sect2><title> </title><para> </para></sect2>
|
||||
|
||||
<sect2>
|
||||
@ -28,9 +27,10 @@ cd ../binutils-build</userinput></screen>
|
||||
|
||||
<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>Before starting to build Binutils, remember to unset any environment
|
||||
@ -41,16 +41,16 @@ variables that override the default optimization flags.</para>
|
||||
<screen><userinput>make</userinput></screen>
|
||||
|
||||
<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>
|
||||
|
||||
|
||||
@ -512,13 +512,15 @@ cc dummy.c
|
||||
readelf -l a.out | grep ': /tools'</userinput></screen>
|
||||
|
||||
<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
|
||||
problem is and correct it. There is no point in continuing until this is done.
|
||||
|
||||
@ -17,16 +17,16 @@ And for the patch:
|
||||
<sect2>
|
||||
<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>
|
||||
|
||||
|
||||
@ -16,13 +16,11 @@ other interactive programs.</para>
|
||||
<sect2>
|
||||
<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>
|
||||
|
||||
<screen><userinput>./configure --prefix=/tools --with-tcl=/tools/lib --with-x=no</userinput></screen>
|
||||
@ -57,8 +55,8 @@ considered critical.)</para>
|
||||
<para>The meaning of the make parameter:</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>
|
||||
|
||||
<para>You can now remove the source directories of both Tcl and Expect.</para>
|
||||
|
||||
@ -15,14 +15,14 @@
|
||||
<sect2>
|
||||
<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
|
||||
directory in a dedicated build directory:</para>
|
||||
@ -52,8 +52,8 @@ 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 <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
|
||||
ensures that only the C compiler is built. The option is only needed when you
|
||||
@ -78,21 +78,17 @@ reproduce itself flawlessly, which most probably means that it was
|
||||
compiled correctly.</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 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
|
||||
<command>cc</command> leaves the system administrator free to decide what
|
||||
|
||||
@ -13,33 +13,33 @@
|
||||
<sect2>
|
||||
<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;
|
||||
patch -Np1 -i ../&gcc-specs-patch;</userinput></screen>
|
||||
@ -56,7 +56,7 @@ directory, resulting in GCC finding the fixed headers from the host system,
|
||||
which would most likely not match the Glibc version actually used for the LFS
|
||||
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
|
||||
path. Patching now rather than adjusting the specs file after installation
|
||||
@ -86,6 +86,14 @@ variables that override the default optimization flags.</para>
|
||||
<para>The meaning of the new configure options:</para>
|
||||
|
||||
<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>
|
||||
|
||||
@ -96,16 +104,8 @@ handling of destructors. It also affects the C++ ABI and therefore results in
|
||||
C++ shared libraries and C++ programs that are interoperable with other Linux
|
||||
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>
|
||||
|
||||
<para>Compile the package:</para>
|
||||
@ -116,7 +116,7 @@ needed to ensure that both C and C++ compilers are built.</para></listitem>
|
||||
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>
|
||||
|
||||
<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
|
||||
so:</para>
|
||||
@ -150,17 +150,18 @@ 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
|
||||
<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>
|
||||
|
||||
@ -168,9 +169,9 @@ to continue on.</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>
|
||||
|
||||
|
||||
@ -13,11 +13,11 @@
|
||||
<sect2>
|
||||
<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
|
||||
is putting the stability of your system at risk.</para>
|
||||
@ -40,7 +40,7 @@ cd ../glibc-build</userinput></screen>
|
||||
<itemizedlist>
|
||||
<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
|
||||
tells Glibc to use the Linuxthreads add-on as its threading
|
||||
@ -71,7 +71,7 @@ suppresses an annoying but harmless warning about a missing
|
||||
*** some features will be disabled.
|
||||
*** 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>
|
||||
|
||||
@ -79,7 +79,7 @@ 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
|
||||
so:</para>
|
||||
@ -90,10 +90,10 @@ so:</para>
|
||||
system, in particular the kernel. Additionally, here in this chapter some tests
|
||||
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>
|
||||
<listitem><para>The <emphasis>math</emphasis> tests sometimes fail when running
|
||||
@ -117,20 +117,19 @@ fail due to test timeouts being exceeded.</para></listitem>
|
||||
</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
|
||||
touch /tools/etc/ld.so.conf</userinput></screen>
|
||||
|
||||
@ -19,8 +19,8 @@ place where <command>gcc</command> can later find them.</para>
|
||||
<screen><userinput>make mrproper</userinput></screen>
|
||||
|
||||
<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>
|
||||
|
||||
<para>Create the <filename>include/linux/version.h</filename> file:</para>
|
||||
|
||||
@ -15,12 +15,12 @@
|
||||
<sect2>
|
||||
<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>
|
||||
|
||||
<para>Prepare Tcl for compilation:</para>
|
||||
|
||||
@ -436,13 +436,15 @@ cc dummy.c
|
||||
readelf -l a.out | grep ': /lib'</userinput></screen>
|
||||
|
||||
<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
|
||||
problem is and correct it. There is no point in continuing until this is done.
|
||||
|
||||
@ -2,8 +2,8 @@
|
||||
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
|
||||
"/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 " ">
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user