mirror of
https://git.linuxfromscratch.org/lfs.git
synced 2025-03-06 06:14:47 +00:00
Removed text in chapter 05 - second round.
git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@4433 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689
This commit is contained in:
Manuel Canales Esparcia
parent
6790655516
commit
fba1478dba
@ -22,6 +22,8 @@ unset SPECFILE</userinput></screen>
|
||||
|
||||
<screen><userinput>rm -f /tools/lib/gcc/*/*/include/{pthread.h,bits/sigthread.h}</userinput></screen>
|
||||
|
||||
<para>Test the tools:</para>
|
||||
|
||||
<screen><userinput>echo 'main(){}' > dummy.c
|
||||
cc dummy.c
|
||||
readelf -l a.out | grep ': /tools'</userinput></screen>
|
||||
|
||||
@ -12,7 +12,6 @@
|
||||
<secondary>tools, pass 1</secondary></indexterm>
|
||||
|
||||
<sect2 role="package"><title/>
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/gcc.xml" xpointer="xpointer(/sect1/sect2[1]/para[1])"/>
|
||||
|
||||
<segmentedlist>
|
||||
<segtitle>&buildtime;</segtitle>
|
||||
@ -20,25 +19,11 @@
|
||||
<seglistitem><seg>4.4 SBU</seg><seg>300 MB</seg></seglistitem>
|
||||
</segmentedlist>
|
||||
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/gcc.xml" xpointer="xpointer(/sect1/sect2[1]/segmentedlist[2])"/>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 role="installation">
|
||||
<title>Installation of GCC</title>
|
||||
|
||||
<para>Unpack only the GCC-core tarball, as we won't be needing the C++ compiler
|
||||
nor the test suite here.</para>
|
||||
|
||||
<para>This package is known to behave badly when you change its default
|
||||
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>
|
||||
|
||||
<para>The GCC documentation recommends building GCC outside of the source
|
||||
directory in a dedicated build directory:</para>
|
||||
|
||||
<screen><userinput>mkdir ../gcc-build
|
||||
cd ../gcc-build</userinput></screen>
|
||||
|
||||
@ -49,92 +34,16 @@ cd ../gcc-build</userinput></screen>
|
||||
--with-local-prefix=/tools --disable-nls \
|
||||
--enable-shared --enable-languages=c</userinput></screen>
|
||||
|
||||
<para>The meaning of the configure options:</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><parameter>CC="gcc -B/usr/bin"</parameter></term>
|
||||
<listitem><para>This parameter fixes a possible problem with building GCC
|
||||
at this stage, first noticed in LFS 5.1.1. If our host uses a new version
|
||||
of Binutils than we compiled, the host compiler may try use features not
|
||||
supported by our new linker, causing compilation errors. By passing the -B
|
||||
flag to gcc, we cause the compiler to temporarily use the host's linker,
|
||||
which solves the problem.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<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
|
||||
system, so this a sensible thing to do.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><parameter>--enable-shared</parameter></term>
|
||||
<listitem><para>This switch may
|
||||
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 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><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
|
||||
have downloaded and unpacked the full GCC tarball.</para></listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
<para>Continue with compiling the package:</para>
|
||||
|
||||
<screen><userinput>make BOOT_LDFLAGS="-static" bootstrap</userinput></screen>
|
||||
|
||||
<para>The meaning of the make parameters:</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><parameter>BOOT_LDFLAGS="-static"</parameter></term>
|
||||
<listitem><para>This tells GCC to link its programs statically.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<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
|
||||
a first round to compile itself a second time, and then again a third time.
|
||||
It then compares these second and third compiles to make sure it can
|
||||
reproduce itself flawlessly, which most probably means that it was
|
||||
compiled correctly.</para></listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
<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>Now install the package:</para>
|
||||
|
||||
<screen><userinput>make install</userinput></screen>
|
||||
|
||||
<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
|
||||
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>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 role="content"><title/>
|
||||
<para>The details on this package are found in <xref linkend="contents-gcc"/>.</para>
|
||||
</sect2>
|
||||
|
||||
</sect1>
|
||||
|
||||
@ -24,68 +24,18 @@
|
||||
<sect2 role="installation">
|
||||
<title>Re-installation of GCC</title>
|
||||
|
||||
<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
|
||||
<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>Check if there is PTYs for the test suites:</para>
|
||||
|
||||
<screen><userinput>expect -c "spawn ls"</userinput></screen>
|
||||
|
||||
<para>The response might be:</para>
|
||||
|
||||
<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
|
||||
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 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 class="directory">gcc-&gcc-version;/</filename> subdirectory.</para>
|
||||
|
||||
<para>First correct a problem and make an essential adjustment:</para>
|
||||
|
||||
<screen><userinput>patch -Np1 -i ../gcc-&gcc-version;-no_fixincludes-1.patch
|
||||
patch -Np1 -i ../gcc-&gcc-version;-specs-2.patch</userinput></screen>
|
||||
|
||||
<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
|
||||
<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
|
||||
<xref linkend="chapter-building-system"/>, after we've installed the newer
|
||||
Glibc, this private include directory would be searched before the system
|
||||
include 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 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
|
||||
ensures that our new dynamic linker gets used during the actual build of GCC.
|
||||
That is, all the final (and temporary) binaries created during the build will
|
||||
link against the new Glibc.</para>
|
||||
|
||||
<important><para>The above patches are <emphasis>critical</emphasis> in ensuring
|
||||
a successful overall build. Do not forget to apply them.</para></important>
|
||||
|
||||
<para>Create a separate build directory again:</para>
|
||||
|
||||
<screen><userinput>mkdir ../gcc-build
|
||||
cd ../gcc-build</userinput></screen>
|
||||
|
||||
<para>Before starting to build GCC, remember to unset any environment
|
||||
variables that override the default optimization flags.</para>
|
||||
|
||||
<para>Now prepare GCC for compilation:</para>
|
||||
|
||||
<screen><userinput>../gcc-&gcc-version;/configure --prefix=/tools \
|
||||
@ -94,83 +44,24 @@ variables that override the default optimization flags.</para>
|
||||
--enable-__cxa_atexit --enable-languages=c,c++ \
|
||||
--disable-libstdcxx-pch</userinput></screen>
|
||||
|
||||
<para>The meaning of the new configure options:</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><parameter>--enable-clocale=gnu</parameter></term>
|
||||
<listitem><para>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>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><parameter>--enable-threads=posix</parameter></term>
|
||||
<listitem><para>This enables
|
||||
C++ exception handling for multi-threaded code.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><parameter>--enable-__cxa_atexit</parameter></term>
|
||||
<listitem><para>This option
|
||||
allows use of __cxa_atexit, rather than atexit, to register C++ destructors for
|
||||
local statics and global objects and is essential for fully standards-compliant
|
||||
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>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<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>
|
||||
|
||||
<varlistentry>
|
||||
<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
|
||||
have no use for it.</para></listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
<para>Compile the package:</para>
|
||||
|
||||
<screen><userinput>make</userinput></screen>
|
||||
|
||||
<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>
|
||||
|
||||
<para>Compilation is now complete. As mentioned earlier, running the test suites
|
||||
for the temporary tools compiled in this chapter is not mandatory. If you want to run the GCC test suite anyway, the following command will do so:</para>
|
||||
|
||||
<screen><userinput>make -k check</userinput></screen>
|
||||
|
||||
<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
|
||||
a summary of the test suite results, run this:</para>
|
||||
<para>To get a summary of the test suite results, run this:</para>
|
||||
|
||||
<screen><userinput>../gcc-&gcc-version;/contrib/test_summary</userinput></screen>
|
||||
|
||||
<para>(For just the summaries, pipe the output through
|
||||
<userinput>grep -A7 Summ</userinput>.)</para>
|
||||
<para>For only the summaries, pipe the output through
|
||||
<userinput>grep -A7 Summ</userinput></para>
|
||||
|
||||
<para>You can compare your results to those posted to the gcc-testresults
|
||||
mailing list for similar configurations to your own. For an example of how
|
||||
<para>Results can be compared to those posted to the gcc-testresults
|
||||
mailing list to see similar configurations to the one being built. For an example of how
|
||||
current GCC-&gcc-version; should look on i686-pc-linux-gnu, see
|
||||
<ulink url="http://gcc.gnu.org/ml/gcc-testresults/2004-11/msg00569.html"/>.</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>
|
||||
|
||||
<screen><userinput>make install</userinput></screen>
|
||||
@ -183,8 +74,4 @@ GCC Specs patch.</para></note>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 role="content"><title/>
|
||||
<para>The details on this package are found in <xref linkend="contents-gcc"/>.</para>
|
||||
</sect2>
|
||||
|
||||
</sect1>
|
||||
|
||||
@ -12,7 +12,6 @@
|
||||
<secondary>tools</secondary></indexterm>
|
||||
|
||||
<sect2 role="package"><title/>
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/gettext.xml" xpointer="xpointer(/sect1/sect2[1]/para[1])"/>
|
||||
|
||||
<segmentedlist>
|
||||
<segtitle>&buildtime;</segtitle>
|
||||
@ -20,8 +19,6 @@
|
||||
<seglistitem><seg>0.5 SBU</seg><seg>55 MB</seg></seglistitem>
|
||||
</segmentedlist>
|
||||
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/gettext.xml" xpointer="xpointer(/sect1/sect2[1]/segmentedlist[2])"/>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 role="installation">
|
||||
@ -32,36 +29,12 @@
|
||||
<screen><userinput>./configure --prefix=/tools --disable-libasprintf \
|
||||
--disable-csharp</userinput></screen>
|
||||
|
||||
<para>The meaning of the configure options:</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><parameter>--disable-libasprintf</parameter></term>
|
||||
<listitem><para>This flag tells
|
||||
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><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.
|
||||
We've already <quote>locked</quote> ourselves into the temporary tools though,
|
||||
which doesn't have a C# compiler.</para></listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
<para>Compile the programs:</para>
|
||||
<para>Compile the package:</para>
|
||||
|
||||
<screen><userinput>make</userinput></screen>
|
||||
|
||||
<para>(If you want to test the results, then issue: <userinput>make
|
||||
check</userinput>. This takes a very long time, around 7 SBUs. Moreover, the
|
||||
Gettext test suite is known to experience failures under certain host
|
||||
conditions -- for example when it finds a Java compiler on the host (but an
|
||||
experimental patch to disable Java is available from the LFS Patches
|
||||
project).)</para>
|
||||
<para>To test the results, issue:
|
||||
<userinput>make check</userinput></para>
|
||||
|
||||
<para>And install the package:</para>
|
||||
|
||||
@ -69,8 +42,4 @@ project).)</para>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 role="content"><title/>
|
||||
<para>The details on this package are found in <xref linkend="contents-gettext"/>.</para>
|
||||
</sect2>
|
||||
|
||||
</sect1>
|
||||
|
||||
@ -12,7 +12,6 @@
|
||||
<secondary>tools</secondary></indexterm>
|
||||
|
||||
<sect2 role="package"><title/>
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/glibc.xml" xpointer="xpointer(/sect1/sect2[1]/para[1])"/>
|
||||
|
||||
<segmentedlist>
|
||||
<segtitle>&buildtime;</segtitle>
|
||||
@ -20,25 +19,11 @@
|
||||
<seglistitem><seg>11.8 SBU</seg><seg>800 MB</seg></seglistitem>
|
||||
</segmentedlist>
|
||||
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/glibc.xml" xpointer="xpointer(/sect1/sect2[1]/segmentedlist[2])"/>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 role="installation">
|
||||
<title>Installation of Glibc</title>
|
||||
|
||||
<para>This package is known to behave badly when you change its default
|
||||
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>
|
||||
|
||||
<para>Basically, compiling Glibc in any other way than the book suggests
|
||||
is putting the stability of your system at risk.</para>
|
||||
|
||||
<para>The Glibc documentation recommends building Glibc outside of the source
|
||||
directory in a dedicated build directory:</para>
|
||||
|
||||
<screen><userinput>mkdir ../glibc-build
|
||||
cd ../glibc-build</userinput></screen>
|
||||
|
||||
@ -49,104 +34,15 @@ cd ../glibc-build</userinput></screen>
|
||||
--enable-kernel=2.6.0 --with-binutils=/tools/bin \
|
||||
--without-gd --without-cvs --with-headers=/tools/include</userinput></screen>
|
||||
|
||||
<para>The meaning of the configure options:</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><parameter>--disable-profile</parameter></term>
|
||||
<listitem><para>This builds the
|
||||
libraries without profiling information. Omit this option if you plan to do
|
||||
profiling on the temporary tools.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><parameter>--enable-add-ons</parameter></term>
|
||||
<listitem><para>This tells Glibc to use the add-on' that it can use like NPTL
|
||||
as its threading library.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><parameter>--enable-kernel=2.6.0</parameter></term>
|
||||
<listitem><para>This tells Glibc to compile the library for support of
|
||||
linux 2.6.x kernels.
|
||||
</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<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
|
||||
Glibc build.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<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
|
||||
(libgd, libpng, libz, and so forth). </para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><parameter>--without-cvs</parameter></term>
|
||||
<listitem><para>This is meant to prevent
|
||||
the Makefiles from attempting automatic CVS checkouts when using a CVS
|
||||
snapshot. But it's not actually needed these days. We use it because it
|
||||
suppresses an annoying but harmless warning about a missing
|
||||
<command>autoconf</command> program.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><parameter>--with-headers=/tools/include</parameter></term>
|
||||
<listitem><para>This forces glibc to use the linux-libc-headers installed
|
||||
in /tools/include, rather than those on the host, which may be too old to
|
||||
support needed functionality.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
</variablelist>
|
||||
|
||||
<para>During this stage you might see the following warning:</para>
|
||||
|
||||
<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.</computeroutput></screen></blockquote>
|
||||
|
||||
<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>
|
||||
|
||||
<para>Compile the package:</para>
|
||||
|
||||
<screen><userinput>make</userinput></screen>
|
||||
|
||||
<para>Compilation is now complete. As mentioned earlier, running the test suites
|
||||
for the temporary tools installed in this chapter is not mandatory. If you want
|
||||
to run the Glibc test suite though, the following command will do so:</para>
|
||||
|
||||
<screen><userinput>make check</userinput></screen>
|
||||
|
||||
<para>For a discussion of test failures that are of particular
|
||||
importance, please see <xref linkend="ch-system-glibc"/>.</para>
|
||||
|
||||
<para>In this chapter, some tests can be adversely affected by existing tools or
|
||||
environmental issues on the host system. In short, don't worry too much if you
|
||||
see Glibc test suite failures 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).</para>
|
||||
|
||||
<para>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>. If you do that though, 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 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>
|
||||
|
||||
@ -154,30 +50,15 @@ touch /tools/etc/ld.so.conf</userinput></screen>
|
||||
|
||||
<screen><userinput>make install</userinput></screen>
|
||||
|
||||
<para>Different countries and cultures have varying conventions for how to
|
||||
communicate. These conventions range from very simple ones, such as the format
|
||||
for representing dates and times, to very complex ones, such as the language
|
||||
spoken. The <quote>internationalization</quote> of GNU programs works by means
|
||||
of <emphasis>locales</emphasis>.</para>
|
||||
|
||||
<note><para>If you are not running the test suites here in this chapter as per
|
||||
our recommendation, there is little point in installing the locales now. We'll
|
||||
be installing the locales in the next chapter.</para></note>
|
||||
|
||||
<para>If you still want to install the Glibc locales anyway, the following
|
||||
command will do so:</para>
|
||||
<para>To install the Glibc locales, use the following
|
||||
command:</para>
|
||||
|
||||
<screen><userinput>make localedata/install-locales</userinput></screen>
|
||||
|
||||
<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
|
||||
<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
|
||||
following instructions, instead of the install-locales target above, will
|
||||
install the minimum set of locales necessary for the tests to run
|
||||
successfully:</para>
|
||||
locales which you need or want. The following instructions, instead of the
|
||||
install-locales target above, will install the minimum set of locales necessary
|
||||
for the tests to run successfully:</para>
|
||||
|
||||
<screen><userinput>mkdir -p /tools/lib/locale
|
||||
localedef -i de_DE -f ISO-8859-1 de_DE
|
||||
@ -194,8 +75,4 @@ localedef -i ja_JP -f EUC-JP ja_JP</userinput></screen>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 role="content"><title/>
|
||||
<para>The details on this package are found in <xref linkend="contents-glibc"/>.</para>
|
||||
</sect2>
|
||||
|
||||
</sect1>
|
||||
|
||||
@ -12,7 +12,6 @@
|
||||
<secondary>tools</secondary></indexterm>
|
||||
|
||||
<sect2 role="package"><title/>
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/grep.xml" xpointer="xpointer(/sect1/sect2[1]/para[1])"/>
|
||||
|
||||
<segmentedlist>
|
||||
<segtitle>&buildtime;</segtitle>
|
||||
@ -20,8 +19,6 @@
|
||||
<seglistitem><seg>0.1 SBU</seg><seg>5.8 MB</seg></seglistitem>
|
||||
</segmentedlist>
|
||||
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/grep.xml" xpointer="xpointer(/sect1/sect2[1]/segmentedlist[2])"/>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 role="installation">
|
||||
@ -32,39 +29,17 @@
|
||||
<screen><userinput>./configure --prefix=/tools \
|
||||
--disable-perl-regexp --with-included-regex</userinput></screen>
|
||||
|
||||
<para>The meaning of the configure options:</para>
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<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
|
||||
available once we enter the chroot environment.</para></listitem>
|
||||
</varlistentry>
|
||||
|
||||
<varlistentry>
|
||||
<term><parameter>--with-included-regex</parameter></term>
|
||||
<listitem><para>This ensures that
|
||||
Grep uses its internal regular expression code. Without this switch, Grep will
|
||||
use the code from Glibc, which is known to be slightly buggy.</para></listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
||||
<para>Compile the programs:</para>
|
||||
<para>Compile the package:</para>
|
||||
|
||||
<screen><userinput>make</userinput></screen>
|
||||
|
||||
<para>(If you want to test the results, then issue:
|
||||
<userinput>make check</userinput>.)</para>
|
||||
<para>To test the results, issue:
|
||||
<userinput>make check</userinput></para>
|
||||
|
||||
<para>Then install them and their documentation:</para>
|
||||
<para>Install the package:</para>
|
||||
|
||||
<screen><userinput>make install</userinput></screen>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 role="content"><title/>
|
||||
<para>The details on this package are found in <xref linkend="contents-grep"/>.</para>
|
||||
</sect2>
|
||||
|
||||
</sect1>
|
||||
|
||||
@ -12,7 +12,6 @@
|
||||
<secondary>tools</secondary></indexterm>
|
||||
|
||||
<sect2 role="package"><title/>
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/gzip.xml" xpointer="xpointer(/sect1/sect2[1]/para[1])"/>
|
||||
|
||||
<segmentedlist>
|
||||
<segtitle>&buildtime;</segtitle>
|
||||
@ -20,8 +19,6 @@
|
||||
<seglistitem><seg>0.1 SBU</seg><seg>2.6 MB</seg></seglistitem>
|
||||
</segmentedlist>
|
||||
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/gzip.xml" xpointer="xpointer(/sect1/sect2[1]/segmentedlist[2])"/>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 role="installation">
|
||||
@ -41,8 +38,4 @@
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 role="content"><title/>
|
||||
<para>The details on this package are found in <xref linkend="contents-gzip"/>.</para>
|
||||
</sect2>
|
||||
|
||||
</sect1>
|
||||
|
||||
@ -7,31 +7,6 @@
|
||||
<title>Host system requirements</title>
|
||||
<?dbhtml filename="hostreqs.html"?>
|
||||
|
||||
<para>Due to the experimental nature of the current book, the host must be
|
||||
running at <emphasis>least</emphasis> a 2.6.2 kernel compiled with GCC-3.0 or
|
||||
higher. There are two main reasons for the high requirement. Firstly, we make
|
||||
use of the Native Posix Threading Library (NPTL) whose testsuite will segfault
|
||||
if the host's kernel hasn't been compiled with GCC-3.0 or later. Secondly, the
|
||||
2.6.2 or later version of the kernel is required for the use of Udev. Udev
|
||||
creates devices dynamically by reading from the
|
||||
<systemitem class="filesystem">sysfs</systemitem> file system. Only very
|
||||
recently has support for this file system been implemented in most of the kernel
|
||||
drivers, however. We must be sure that all the critical system devices get
|
||||
created properly.</para>
|
||||
|
||||
<para>In order to check that your host kernel meets the requirements outlined
|
||||
above, you can run the following command:</para>
|
||||
|
||||
<screen><userinput>cat /proc/version</userinput></screen>
|
||||
|
||||
<para>This will produce output similar to:</para>
|
||||
|
||||
<blockquote><screen><computeroutput>Linux version 2.6.2 (user@host) (gcc version 3.4.0) #1 Tue Apr 20 21:22:18 GMT 2004</computeroutput></screen></blockquote>
|
||||
|
||||
<para>If the results of the above command state that your host kernel wasn't
|
||||
compiled using a GCC-3.0 (or later) compiler, you will need to compile one
|
||||
yourself, and reboot your host to use the newly compiled kernel. Instructions
|
||||
for compiling the kernel and configuring the bootloader (assuming your host uses
|
||||
GRUB) are given in <xref linkend="chapter-bootable"/>.</para>
|
||||
<para>See testing.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
@ -7,58 +7,6 @@
|
||||
<title>Introduction</title>
|
||||
<?dbhtml filename="introduction.html"?>
|
||||
|
||||
<para>In this chapter we will compile and install a minimal
|
||||
Linux system. This system will contain just enough tools to be able
|
||||
to start constructing the final LFS system in the next chapter and allow
|
||||
a working environment with a little more user convenience than a minimum
|
||||
environment.</para>
|
||||
|
||||
<para>The building of this minimal system is done in two steps: first we
|
||||
build a brand-new and host-independent toolchain (compiler, assembler,
|
||||
linker, libraries, and a few useful utilities), and then use this to build all the other essential
|
||||
tools.</para>
|
||||
|
||||
<para>The files compiled in this chapter will be installed under the
|
||||
<filename class="directory">$LFS/tools</filename> directory
|
||||
to keep them separate from the files installed in the next chapter and your host's production directories.
|
||||
Since the packages compiled here are merely temporary, we don't want
|
||||
them to pollute the soon-to-be LFS system.</para>
|
||||
|
||||
<para>Before issuing the build instructions for a package, you are expected to
|
||||
have already unpacked it (explained shortly) as user <emphasis>lfs</emphasis>,
|
||||
and to have performed a <userinput>cd</userinput> into the created directory.
|
||||
The build instructions assume that you are using the <command>bash</command>
|
||||
shell.</para>
|
||||
|
||||
<para>Several of the packages are patched before compilation, but only when
|
||||
the patch is needed to circumvent a problem. Often the patch is needed in
|
||||
both this and the next chapter, but sometimes in only one of them. Therefore,
|
||||
don't worry when instructions for a downloaded patch seem to be missing. Also,
|
||||
when applying a patch, you'll occasionally see warning messages about
|
||||
<emphasis>offset</emphasis> or <emphasis>fuzz</emphasis>. These warnings are
|
||||
nothing to worry about, as the patch was still successfully applied.</para>
|
||||
|
||||
<para>During the compilation of most packages you will see many warnings
|
||||
scroll by on your screen. These are normal and can safely be ignored. They are
|
||||
just what they say they are: warnings -- mostly about deprecated, but not
|
||||
invalid, use of the C or C++ syntax. It's just that C standards have changed
|
||||
rather often and some packages still use the older standard, which is not
|
||||
really a problem.</para>
|
||||
|
||||
<para>After installing each package you should delete its source and build
|
||||
directories, <emphasis>unless</emphasis> told otherwise. Deleting the sources
|
||||
saves space, but also prevents mis-configuration when the same package is
|
||||
reinstalled further on. Only for three packages you will need to keep the
|
||||
source and build directories around for a while, so their contents can be used
|
||||
by later commands. Do not miss the reminders.</para>
|
||||
|
||||
<para>Now first check that your LFS environment variable is set up
|
||||
properly:</para>
|
||||
|
||||
<screen><userinput>echo $LFS</userinput></screen>
|
||||
|
||||
<para>Make sure the output shows the path to your LFS partition's mount
|
||||
point, which is <filename class="directory">/mnt/lfs</filename> if you
|
||||
followed our example.</para>
|
||||
<para>See testing.</para>
|
||||
|
||||
</sect1>
|
||||
|
||||
@ -1,61 +0,0 @@
|
||||
<?xml version="1.0" encoding="ISO-8859-1"?>
|
||||
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
|
||||
<!ENTITY % general-entities SYSTEM "../general.ent">
|
||||
%general-entities;
|
||||
]>
|
||||
<sect1 id="ch-tools-kernel-headers" role="wrap">
|
||||
<title>Linux-&linux-version; headers</title>
|
||||
<?dbhtml filename="kernel-headers.html"?>
|
||||
|
||||
<indexterm zone="ch-tools-kernel-headers">
|
||||
<primary sortas="a-Linux">Linux</primary>
|
||||
<secondary>tools, headers</secondary></indexterm>
|
||||
|
||||
<sect2 role="package"><title/>
|
||||
|
||||
<segmentedlist>
|
||||
<segtitle>&buildtime;</segtitle>
|
||||
<segtitle>&diskspace;</segtitle>
|
||||
<seglistitem><seg>0.1 SBU</seg><seg>186 MB</seg></seglistitem>
|
||||
</segmentedlist>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 role="installation">
|
||||
<title>Installation of the kernel headers</title>
|
||||
|
||||
<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 <command>gcc</command> can later find them.</para>
|
||||
|
||||
<para>Prepare for the header installation with:</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
|
||||
un-tarring.</para>
|
||||
|
||||
<para>Create the <filename>include/linux/version.h</filename> file:</para>
|
||||
|
||||
<screen><userinput>make include/linux/version.h</userinput></screen>
|
||||
|
||||
<para>Create the platform-specific <filename class="symlink">include/asm</filename>
|
||||
symlink:</para>
|
||||
|
||||
<screen><userinput>make include/asm</userinput></screen>
|
||||
|
||||
<para>Install the platform-specific header files:</para>
|
||||
|
||||
<screen><userinput>mkdir /tools/glibc-kernheaders
|
||||
cp -HR include/asm /tools/glibc-kernheaders
|
||||
cp -R include/asm-generic /tools/glibc-kernheaders</userinput></screen>
|
||||
|
||||
<para>Finally, install the cross-platform kernel header files:</para>
|
||||
|
||||
<screen><userinput>cp -R include/linux /tools/glibc-kernheaders</userinput></screen>
|
||||
|
||||
</sect2>
|
||||
|
||||
</sect1>
|
||||
@ -24,12 +24,6 @@
|
||||
<sect2 role="installation">
|
||||
<title>Installation of Linux-Libc-Headers</title>
|
||||
|
||||
<para>For years it has been common practice to use so-called <quote>raw</quote>
|
||||
kernel headers (straight from a kernel tarball) in <filename class="directory">/usr/include</filename>, but over the
|
||||
last few years, the kernel developers have taken a strong stance that such
|
||||
things should not be done. Thus was born the linux-libc-headers project,
|
||||
designed to maintain an API stable version of the Linux headers.</para>
|
||||
|
||||
<para>Install the header files:</para>
|
||||
|
||||
<screen><userinput>cp -R include/asm-i386 /tools/include/asm
|
||||
|
||||
@ -12,7 +12,6 @@
|
||||
<secondary>tools</secondary></indexterm>
|
||||
|
||||
<sect2 role="package"><title/>
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/m4.xml" xpointer="xpointer(/sect1/sect2[1]/para[1])"/>
|
||||
|
||||
<segmentedlist>
|
||||
<segtitle>&buildtime;</segtitle>
|
||||
@ -20,8 +19,6 @@
|
||||
<seglistitem><seg>0.1 SBU</seg><seg>3.0 MB</seg></seglistitem>
|
||||
</segmentedlist>
|
||||
|
||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/m4.xml" xpointer="xpointer(/sect1/sect2[1]/segmentedlist[2])"/>
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 role="installation">
|
||||
@ -44,8 +41,4 @@
|
||||
|
||||
</sect2>
|
||||
|
||||
<sect2 role="content"><title/>
|
||||
<para>The details on this package are found in <xref linkend="contents-m4"/>.</para>
|
||||
</sect2>
|
||||
|
||||
</sect1>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user