mirror of
https://git.linuxfromscratch.org/lfs.git
synced 2025-07-14 00:05:09 +01: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>
|
<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
|
<screen><userinput>echo 'main(){}' > dummy.c
|
||||||
cc dummy.c
|
cc dummy.c
|
||||||
readelf -l a.out | grep ': /tools'</userinput></screen>
|
readelf -l a.out | grep ': /tools'</userinput></screen>
|
||||||
|
|||||||
@ -12,7 +12,6 @@
|
|||||||
<secondary>tools, pass 1</secondary></indexterm>
|
<secondary>tools, pass 1</secondary></indexterm>
|
||||||
|
|
||||||
<sect2 role="package"><title/>
|
<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>
|
<segmentedlist>
|
||||||
<segtitle>&buildtime;</segtitle>
|
<segtitle>&buildtime;</segtitle>
|
||||||
@ -20,25 +19,11 @@
|
|||||||
<seglistitem><seg>4.4 SBU</seg><seg>300 MB</seg></seglistitem>
|
<seglistitem><seg>4.4 SBU</seg><seg>300 MB</seg></seglistitem>
|
||||||
</segmentedlist>
|
</segmentedlist>
|
||||||
|
|
||||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/gcc.xml" xpointer="xpointer(/sect1/sect2[1]/segmentedlist[2])"/>
|
|
||||||
|
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
<sect2 role="installation">
|
<sect2 role="installation">
|
||||||
<title>Installation of GCC</title>
|
<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
|
<screen><userinput>mkdir ../gcc-build
|
||||||
cd ../gcc-build</userinput></screen>
|
cd ../gcc-build</userinput></screen>
|
||||||
|
|
||||||
@ -49,92 +34,16 @@ cd ../gcc-build</userinput></screen>
|
|||||||
--with-local-prefix=/tools --disable-nls \
|
--with-local-prefix=/tools --disable-nls \
|
||||||
--enable-shared --enable-languages=c</userinput></screen>
|
--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>
|
<para>Continue with compiling the package:</para>
|
||||||
|
|
||||||
<screen><userinput>make BOOT_LDFLAGS="-static" bootstrap</userinput></screen>
|
<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>
|
<para>Now install the package:</para>
|
||||||
|
|
||||||
<screen><userinput>make install</userinput></screen>
|
<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>
|
<screen><userinput>ln -s gcc /tools/bin/cc</userinput></screen>
|
||||||
|
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
<sect2 role="content"><title/>
|
|
||||||
<para>The details on this package are found in <xref linkend="contents-gcc"/>.</para>
|
|
||||||
</sect2>
|
|
||||||
|
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|||||||
@ -24,68 +24,18 @@
|
|||||||
<sect2 role="installation">
|
<sect2 role="installation">
|
||||||
<title>Re-installation of GCC</title>
|
<title>Re-installation of GCC</title>
|
||||||
|
|
||||||
<para>The tools required to test GCC and Binutils are installed now: Tcl,
|
<para>Check if there is PTYs for the test suites:</para>
|
||||||
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>
|
|
||||||
|
|
||||||
<screen><userinput>expect -c "spawn ls"</userinput></screen>
|
<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
|
<screen><userinput>patch -Np1 -i ../gcc-&gcc-version;-no_fixincludes-1.patch
|
||||||
patch -Np1 -i ../gcc-&gcc-version;-specs-2.patch</userinput></screen>
|
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>
|
<para>Create a separate build directory again:</para>
|
||||||
|
|
||||||
<screen><userinput>mkdir ../gcc-build
|
<screen><userinput>mkdir ../gcc-build
|
||||||
cd ../gcc-build</userinput></screen>
|
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>
|
<para>Now prepare GCC for compilation:</para>
|
||||||
|
|
||||||
<screen><userinput>../gcc-&gcc-version;/configure --prefix=/tools \
|
<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++ \
|
--enable-__cxa_atexit --enable-languages=c,c++ \
|
||||||
--disable-libstdcxx-pch</userinput></screen>
|
--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>
|
<para>Compile the package:</para>
|
||||||
|
|
||||||
<screen><userinput>make</userinput></screen>
|
<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>
|
<screen><userinput>make -k check</userinput></screen>
|
||||||
|
|
||||||
<para>The <parameter>-k</parameter> flag is used to make the test suite run
|
<para>To get a summary of the test suite results, run this:</para>
|
||||||
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>
|
|
||||||
|
|
||||||
<screen><userinput>../gcc-&gcc-version;/contrib/test_summary</userinput></screen>
|
<screen><userinput>../gcc-&gcc-version;/contrib/test_summary</userinput></screen>
|
||||||
|
|
||||||
<para>(For just the summaries, pipe the output through
|
<para>For only the summaries, pipe the output through
|
||||||
<userinput>grep -A7 Summ</userinput>.)</para>
|
<userinput>grep -A7 Summ</userinput></para>
|
||||||
|
|
||||||
<para>You can compare your results to those posted to the gcc-testresults
|
<para>Results can be compared to those posted to the gcc-testresults
|
||||||
mailing list for similar configurations to your own. For an example of how
|
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
|
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>
|
<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>
|
<para>And finally install the package:</para>
|
||||||
|
|
||||||
<screen><userinput>make install</userinput></screen>
|
<screen><userinput>make install</userinput></screen>
|
||||||
@ -183,8 +74,4 @@ GCC Specs patch.</para></note>
|
|||||||
|
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
<sect2 role="content"><title/>
|
|
||||||
<para>The details on this package are found in <xref linkend="contents-gcc"/>.</para>
|
|
||||||
</sect2>
|
|
||||||
|
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|||||||
@ -12,7 +12,6 @@
|
|||||||
<secondary>tools</secondary></indexterm>
|
<secondary>tools</secondary></indexterm>
|
||||||
|
|
||||||
<sect2 role="package"><title/>
|
<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>
|
<segmentedlist>
|
||||||
<segtitle>&buildtime;</segtitle>
|
<segtitle>&buildtime;</segtitle>
|
||||||
@ -20,8 +19,6 @@
|
|||||||
<seglistitem><seg>0.5 SBU</seg><seg>55 MB</seg></seglistitem>
|
<seglistitem><seg>0.5 SBU</seg><seg>55 MB</seg></seglistitem>
|
||||||
</segmentedlist>
|
</segmentedlist>
|
||||||
|
|
||||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/gettext.xml" xpointer="xpointer(/sect1/sect2[1]/segmentedlist[2])"/>
|
|
||||||
|
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
<sect2 role="installation">
|
<sect2 role="installation">
|
||||||
@ -32,36 +29,12 @@
|
|||||||
<screen><userinput>./configure --prefix=/tools --disable-libasprintf \
|
<screen><userinput>./configure --prefix=/tools --disable-libasprintf \
|
||||||
--disable-csharp</userinput></screen>
|
--disable-csharp</userinput></screen>
|
||||||
|
|
||||||
<para>The meaning of the configure options:</para>
|
<para>Compile the package:</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>
|
|
||||||
|
|
||||||
<screen><userinput>make</userinput></screen>
|
<screen><userinput>make</userinput></screen>
|
||||||
|
|
||||||
<para>(If you want to test the results, then issue: <userinput>make
|
<para>To test the results, issue:
|
||||||
check</userinput>. This takes a very long time, around 7 SBUs. Moreover, the
|
<userinput>make check</userinput></para>
|
||||||
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>And install the package:</para>
|
<para>And install the package:</para>
|
||||||
|
|
||||||
@ -69,8 +42,4 @@ project).)</para>
|
|||||||
|
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
<sect2 role="content"><title/>
|
|
||||||
<para>The details on this package are found in <xref linkend="contents-gettext"/>.</para>
|
|
||||||
</sect2>
|
|
||||||
|
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|||||||
@ -12,7 +12,6 @@
|
|||||||
<secondary>tools</secondary></indexterm>
|
<secondary>tools</secondary></indexterm>
|
||||||
|
|
||||||
<sect2 role="package"><title/>
|
<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>
|
<segmentedlist>
|
||||||
<segtitle>&buildtime;</segtitle>
|
<segtitle>&buildtime;</segtitle>
|
||||||
@ -20,25 +19,11 @@
|
|||||||
<seglistitem><seg>11.8 SBU</seg><seg>800 MB</seg></seglistitem>
|
<seglistitem><seg>11.8 SBU</seg><seg>800 MB</seg></seglistitem>
|
||||||
</segmentedlist>
|
</segmentedlist>
|
||||||
|
|
||||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/glibc.xml" xpointer="xpointer(/sect1/sect2[1]/segmentedlist[2])"/>
|
|
||||||
|
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
<sect2 role="installation">
|
<sect2 role="installation">
|
||||||
<title>Installation of Glibc</title>
|
<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
|
<screen><userinput>mkdir ../glibc-build
|
||||||
cd ../glibc-build</userinput></screen>
|
cd ../glibc-build</userinput></screen>
|
||||||
|
|
||||||
@ -49,104 +34,15 @@ cd ../glibc-build</userinput></screen>
|
|||||||
--enable-kernel=2.6.0 --with-binutils=/tools/bin \
|
--enable-kernel=2.6.0 --with-binutils=/tools/bin \
|
||||||
--without-gd --without-cvs --with-headers=/tools/include</userinput></screen>
|
--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>
|
<para>Compile the package:</para>
|
||||||
|
|
||||||
<screen><userinput>make</userinput></screen>
|
<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>
|
<screen><userinput>make check</userinput></screen>
|
||||||
|
|
||||||
<para>For a discussion of test failures that are of particular
|
<para>For a discussion of test failures that are of particular
|
||||||
importance, please see <xref linkend="ch-system-glibc"/>.</para>
|
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
|
<screen><userinput>mkdir /tools/etc
|
||||||
touch /tools/etc/ld.so.conf</userinput></screen>
|
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>
|
<screen><userinput>make install</userinput></screen>
|
||||||
|
|
||||||
<para>Different countries and cultures have varying conventions for how to
|
<para>To install the Glibc locales, use the following
|
||||||
communicate. These conventions range from very simple ones, such as the format
|
command:</para>
|
||||||
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>
|
|
||||||
|
|
||||||
<screen><userinput>make localedata/install-locales</userinput></screen>
|
<screen><userinput>make localedata/install-locales</userinput></screen>
|
||||||
|
|
||||||
<para>An alternative to running the previous command is to install only those
|
<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
|
locales which you need or want. The following instructions, instead of the
|
||||||
<command>localedef</command> command. Information on this can be found in
|
install-locales target above, will install the minimum set of locales necessary
|
||||||
the <filename>INSTALL</filename> file in the Glibc source. However, there are
|
for the tests to run successfully:</para>
|
||||||
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>
|
|
||||||
|
|
||||||
<screen><userinput>mkdir -p /tools/lib/locale
|
<screen><userinput>mkdir -p /tools/lib/locale
|
||||||
localedef -i de_DE -f ISO-8859-1 de_DE
|
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>
|
||||||
|
|
||||||
<sect2 role="content"><title/>
|
|
||||||
<para>The details on this package are found in <xref linkend="contents-glibc"/>.</para>
|
|
||||||
</sect2>
|
|
||||||
|
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|||||||
@ -12,7 +12,6 @@
|
|||||||
<secondary>tools</secondary></indexterm>
|
<secondary>tools</secondary></indexterm>
|
||||||
|
|
||||||
<sect2 role="package"><title/>
|
<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>
|
<segmentedlist>
|
||||||
<segtitle>&buildtime;</segtitle>
|
<segtitle>&buildtime;</segtitle>
|
||||||
@ -20,8 +19,6 @@
|
|||||||
<seglistitem><seg>0.1 SBU</seg><seg>5.8 MB</seg></seglistitem>
|
<seglistitem><seg>0.1 SBU</seg><seg>5.8 MB</seg></seglistitem>
|
||||||
</segmentedlist>
|
</segmentedlist>
|
||||||
|
|
||||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/grep.xml" xpointer="xpointer(/sect1/sect2[1]/segmentedlist[2])"/>
|
|
||||||
|
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
<sect2 role="installation">
|
<sect2 role="installation">
|
||||||
@ -32,39 +29,17 @@
|
|||||||
<screen><userinput>./configure --prefix=/tools \
|
<screen><userinput>./configure --prefix=/tools \
|
||||||
--disable-perl-regexp --with-included-regex</userinput></screen>
|
--disable-perl-regexp --with-included-regex</userinput></screen>
|
||||||
|
|
||||||
<para>The meaning of the configure options:</para>
|
<para>Compile the package:</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>
|
|
||||||
|
|
||||||
<screen><userinput>make</userinput></screen>
|
<screen><userinput>make</userinput></screen>
|
||||||
|
|
||||||
<para>(If you want to test the results, then issue:
|
<para>To test the results, issue:
|
||||||
<userinput>make check</userinput>.)</para>
|
<userinput>make check</userinput></para>
|
||||||
|
|
||||||
<para>Then install them and their documentation:</para>
|
<para>Install the package:</para>
|
||||||
|
|
||||||
<screen><userinput>make install</userinput></screen>
|
<screen><userinput>make install</userinput></screen>
|
||||||
|
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
<sect2 role="content"><title/>
|
|
||||||
<para>The details on this package are found in <xref linkend="contents-grep"/>.</para>
|
|
||||||
</sect2>
|
|
||||||
|
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|||||||
@ -12,7 +12,6 @@
|
|||||||
<secondary>tools</secondary></indexterm>
|
<secondary>tools</secondary></indexterm>
|
||||||
|
|
||||||
<sect2 role="package"><title/>
|
<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>
|
<segmentedlist>
|
||||||
<segtitle>&buildtime;</segtitle>
|
<segtitle>&buildtime;</segtitle>
|
||||||
@ -20,8 +19,6 @@
|
|||||||
<seglistitem><seg>0.1 SBU</seg><seg>2.6 MB</seg></seglistitem>
|
<seglistitem><seg>0.1 SBU</seg><seg>2.6 MB</seg></seglistitem>
|
||||||
</segmentedlist>
|
</segmentedlist>
|
||||||
|
|
||||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/gzip.xml" xpointer="xpointer(/sect1/sect2[1]/segmentedlist[2])"/>
|
|
||||||
|
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
<sect2 role="installation">
|
<sect2 role="installation">
|
||||||
@ -41,8 +38,4 @@
|
|||||||
|
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
<sect2 role="content"><title/>
|
|
||||||
<para>The details on this package are found in <xref linkend="contents-gzip"/>.</para>
|
|
||||||
</sect2>
|
|
||||||
|
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|||||||
@ -7,31 +7,6 @@
|
|||||||
<title>Host system requirements</title>
|
<title>Host system requirements</title>
|
||||||
<?dbhtml filename="hostreqs.html"?>
|
<?dbhtml filename="hostreqs.html"?>
|
||||||
|
|
||||||
<para>Due to the experimental nature of the current book, the host must be
|
<para>See testing.</para>
|
||||||
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>
|
|
||||||
|
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|||||||
@ -7,58 +7,6 @@
|
|||||||
<title>Introduction</title>
|
<title>Introduction</title>
|
||||||
<?dbhtml filename="introduction.html"?>
|
<?dbhtml filename="introduction.html"?>
|
||||||
|
|
||||||
<para>In this chapter we will compile and install a minimal
|
<para>See testing.</para>
|
||||||
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>
|
|
||||||
|
|
||||||
</sect1>
|
</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">
|
<sect2 role="installation">
|
||||||
<title>Installation of Linux-Libc-Headers</title>
|
<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>
|
<para>Install the header files:</para>
|
||||||
|
|
||||||
<screen><userinput>cp -R include/asm-i386 /tools/include/asm
|
<screen><userinput>cp -R include/asm-i386 /tools/include/asm
|
||||||
|
|||||||
@ -12,7 +12,6 @@
|
|||||||
<secondary>tools</secondary></indexterm>
|
<secondary>tools</secondary></indexterm>
|
||||||
|
|
||||||
<sect2 role="package"><title/>
|
<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>
|
<segmentedlist>
|
||||||
<segtitle>&buildtime;</segtitle>
|
<segtitle>&buildtime;</segtitle>
|
||||||
@ -20,8 +19,6 @@
|
|||||||
<seglistitem><seg>0.1 SBU</seg><seg>3.0 MB</seg></seglistitem>
|
<seglistitem><seg>0.1 SBU</seg><seg>3.0 MB</seg></seglistitem>
|
||||||
</segmentedlist>
|
</segmentedlist>
|
||||||
|
|
||||||
<xi:include xmlns:xi="http://www.w3.org/2003/XInclude" href="../chapter06/m4.xml" xpointer="xpointer(/sect1/sect2[1]/segmentedlist[2])"/>
|
|
||||||
|
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
<sect2 role="installation">
|
<sect2 role="installation">
|
||||||
@ -44,8 +41,4 @@
|
|||||||
|
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
<sect2 role="content"><title/>
|
|
||||||
<para>The details on this package are found in <xref linkend="contents-m4"/>.</para>
|
|
||||||
</sect2>
|
|
||||||
|
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user