From fba1478dba9095f0007730e844793ad38d9b5af2 Mon Sep 17 00:00:00 2001 From: Manuel Canales Esparcia Date: Mon, 20 Dec 2004 17:23:16 +0000 Subject: Removed text in chapter 05 - second round. git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@4433 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689 --- chapter05/adjusting.xml | 2 + chapter05/gcc-pass1.xml | 91 --------------------------- chapter05/gcc-pass2.xml | 125 ++---------------------------------- chapter05/gettext.xml | 37 +---------- chapter05/glibc.xml | 133 ++------------------------------------- chapter05/grep.xml | 33 ++-------- chapter05/gzip.xml | 7 --- chapter05/hostreqs.xml | 27 +------- chapter05/introduction.xml | 54 +--------------- chapter05/kernel-headers.xml | 61 ------------------ chapter05/linux-libc-headers.xml | 6 -- chapter05/m4.xml | 7 --- 12 files changed, 22 insertions(+), 561 deletions(-) delete mode 100644 chapter05/kernel-headers.xml diff --git a/chapter05/adjusting.xml b/chapter05/adjusting.xml index 6d3aca31f..c3d584ab2 100644 --- a/chapter05/adjusting.xml +++ b/chapter05/adjusting.xml @@ -22,6 +22,8 @@ unset SPECFILE rm -f /tools/lib/gcc/*/*/include/{pthread.h,bits/sigthread.h} +Test the tools: + echo 'main(){}' > dummy.c cc dummy.c readelf -l a.out | grep ': /tools' diff --git a/chapter05/gcc-pass1.xml b/chapter05/gcc-pass1.xml index 9fa5601bb..81f934e04 100644 --- a/chapter05/gcc-pass1.xml +++ b/chapter05/gcc-pass1.xml @@ -12,7 +12,6 @@ tools, pass 1 -<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 -Unpack only the GCC-core tarball, as we won't be needing the C++ compiler -nor the test suite here. - -This package is known to behave badly when you change 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 un-setting them when building GCC. - -The GCC documentation recommends building GCC outside of the source -directory in a dedicated build directory: - mkdir ../gcc-build cd ../gcc-build @@ -49,92 +34,16 @@ cd ../gcc-build --with-local-prefix=/tools --disable-nls \ --enable-shared --enable-languages=c -The meaning of the configure options: - - - -CC="gcc -B/usr/bin" -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. - - - ---with-local-prefix=/tools -The purpose of this switch is to remove /usr/local/include -from gcc'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. - - - ---enable-shared -This switch may -seem counter-intuitive at first. But using it allows the building of -libgcc_s.so.1 and libgcc_eh.a, and -having libgcc_eh.a 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 -static -value of BOOT_LDFLAGS in the next step. - - - ---enable-languages=c -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. - - - Continue with compiling the package: make BOOT_LDFLAGS="-static" bootstrap -The meaning of the make parameters: - - - -BOOT_LDFLAGS="-static" -This tells GCC to link its programs statically. - - - -bootstrap -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. - - - -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. - Now install the package: make install -As a finishing touch we'll create a symlink. Many programs and scripts -run cc instead of gcc, -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 -cc leaves the system administrator free to decide what -C compiler to install, as long as there's a symlink pointing to it: - ln -s gcc /tools/bin/cc - -<para>The details on this package are found in <xref linkend="contents-gcc"/>.</para> -</sect2> - </sect1> diff --git a/chapter05/gcc-pass2.xml b/chapter05/gcc-pass2.xml index 398d43f48..7c3f01d44 100644 --- a/chapter05/gcc-pass2.xml +++ b/chapter05/gcc-pass2.xml @@ -24,68 +24,18 @@ <sect2 role="installation"> <title>Re-installation of GCC -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 -devpts file system. You can quickly check if your host -system is set up correctly in this regard by performing a simple test: +Check if there is PTYs for the test suites: expect -c "spawn ls" -The response might be: - -
The system has no more ptys. Ask your system administrator to create more.
- -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 for more information on how to get PTYs -working. - -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 gcc-&gcc-version;/ subdirectory. - -First correct a problem and make an essential adjustment: - patch -Np1 -i ../gcc-&gcc-version;-no_fixincludes-1.patch patch -Np1 -i ../gcc-&gcc-version;-specs-2.patch -The first patch disables the GCC fixincludes 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 -fixincludes 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 -, 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. - -The second patch changes GCC's default location of the dynamic linker -(typically ld-linux.so.2). It also removes -/usr/include 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. - -The above patches are critical in ensuring -a successful overall build. Do not forget to apply them. - Create a separate build directory again: mkdir ../gcc-build cd ../gcc-build -Before starting to build GCC, remember to unset any environment -variables that override the default optimization flags. - Now prepare GCC for compilation: ../gcc-&gcc-version;/configure --prefix=/tools \ @@ -94,83 +44,24 @@ variables that override the default optimization flags. --enable-__cxa_atexit --enable-languages=c,c++ \ --disable-libstdcxx-pch -The meaning of the new configure options: - - - ---enable-clocale=gnu -This option -ensures the correct locale model is selected for the C++ libraries under all -circumstances. If the configure script finds the de_DE -locale installed, it will select the correct gnu locale -model. However, people who don't install the de_DE locale -would run the risk of building ABI incompatible C++ libraries due to the wrong -generic locale model being selected. - - - ---enable-threads=posix -This enables -C++ exception handling for multi-threaded code. - - - ---enable-__cxa_atexit -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. - - - ---enable-languages=c,c++ -This option -ensures that both the C and C++ compilers are built. - - - ---disable-libstdcxx-pch -Don't build the -PCH (pre-compiled header) for libstdc++. It takes up a ton of space, and we -have no use for it. - - - Compile the package: make -There is no need to use the bootstrap 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. - -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: - make -k check -The -k 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: +To get a summary of the test suite results, run this: ../gcc-&gcc-version;/contrib/test_summary -(For just the summaries, pipe the output through -grep -A7 Summ.) +For only the summaries, pipe the output through +grep -A7 Summ -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 +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 . -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. - And finally install the package: make install @@ -183,8 +74,4 @@ GCC Specs patch. - -<para>The details on this package are found in <xref linkend="contents-gcc"/>.</para> -</sect2> - </sect1> diff --git a/chapter05/gettext.xml b/chapter05/gettext.xml index d88a1a358..f430deb5f 100644 --- a/chapter05/gettext.xml +++ b/chapter05/gettext.xml @@ -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> diff --git a/chapter05/glibc.xml b/chapter05/glibc.xml index 3b7ac093a..b256792f1 100644 --- a/chapter05/glibc.xml +++ b/chapter05/glibc.xml @@ -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 -This package is known to behave badly when you change 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 un-setting them when building Glibc. - -Basically, compiling Glibc in any other way than the book suggests -is putting the stability of your system at risk. - -The Glibc documentation recommends building Glibc outside of the source -directory in a dedicated build directory: - mkdir ../glibc-build cd ../glibc-build @@ -49,104 +34,15 @@ cd ../glibc-build --enable-kernel=2.6.0 --with-binutils=/tools/bin \ --without-gd --without-cvs --with-headers=/tools/include -The meaning of the configure options: - - - ---disable-profile -This builds the -libraries without profiling information. Omit this option if you plan to do -profiling on the temporary tools. - - - ---enable-add-ons -This tells Glibc to use the add-on' that it can use like NPTL -as its threading library. - - - ---enable-kernel=2.6.0 -This tells Glibc to compile the library for support of -linux 2.6.x kernels. - - - - ---with-binutils=/tools/bin -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. - - - ---without-gd -This prevents the build of the memusagestat -program, which strangely enough insists on linking against the host's libraries -(libgd, libpng, libz, and so forth). - - - ---without-cvs -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 -autoconf program. - - - ---with-headers=/tools/include -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. - - - - -During this stage you might see the following warning: - -
configure: WARNING: -*** These auxiliary programs are missing or incompatible versions: msgfmt -*** some features will be disabled. -*** Check the INSTALL file for required versions.
- -The missing or incompatible msgfmt program is -generally harmless, but it's believed it can sometimes cause problems when -running the test suite. - Compile the package: make -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: - make check For a discussion of test failures that are of particular importance, please see . -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 - 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 math tests, -for example). - -When experiencing a failure, make a note of it, then continue by reissuing -the make check. The test suite should pick up where it left -off and continue. You can circumvent this stop-start sequence by issuing a -make -k check. 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. - -Though it is a harmless message, the install stage of Glibc will at the -end complain about the absence of /tools/etc/ld.so.conf. -Prevent this confusing little warning with: - mkdir /tools/etc touch /tools/etc/ld.so.conf @@ -154,30 +50,15 @@ touch /tools/etc/ld.so.conf make install -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 internationalization of GNU programs works by means -of locales. - -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. - -If you still want to install the Glibc locales anyway, the following -command will do so: +To install the Glibc locales, use the following +command: make localedata/install-locales 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 -localedef command. Information on this can be found in -the INSTALL 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 libstdc++ 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: +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: 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 - -<para>The details on this package are found in <xref linkend="contents-glibc"/>.</para> -</sect2> - </sect1> diff --git a/chapter05/grep.xml b/chapter05/grep.xml index 9fcdaca18..c95433cff 100644 --- a/chapter05/grep.xml +++ b/chapter05/grep.xml @@ -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> diff --git a/chapter05/gzip.xml b/chapter05/gzip.xml index 045648cf4..da725178b 100644 --- a/chapter05/gzip.xml +++ b/chapter05/gzip.xml @@ -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> diff --git a/chapter05/hostreqs.xml b/chapter05/hostreqs.xml index fb34e8db7..119d796a3 100644 --- a/chapter05/hostreqs.xml +++ b/chapter05/hostreqs.xml @@ -7,31 +7,6 @@ <title>Host system requirements -Due to the experimental nature of the current book, the host must be -running at least 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 -sysfs 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. - -In order to check that your host kernel meets the requirements outlined -above, you can run the following command: - -cat /proc/version - -This will produce output similar to: - -
Linux version 2.6.2 (user@host) (gcc version 3.4.0) #1 Tue Apr 20 21:22:18 GMT 2004
- -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 . +See testing. diff --git a/chapter05/introduction.xml b/chapter05/introduction.xml index 78c883ecd..eaf2f7b2c 100644 --- a/chapter05/introduction.xml +++ b/chapter05/introduction.xml @@ -7,58 +7,6 @@ Introduction -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. - -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. - -The files compiled in this chapter will be installed under the -$LFS/tools 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. - -Before issuing the build instructions for a package, you are expected to -have already unpacked it (explained shortly) as user lfs, -and to have performed a cd into the created directory. -The build instructions assume that you are using the bash -shell. - -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 -offset or fuzz. These warnings are -nothing to worry about, as the patch was still successfully applied. - -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. - -After installing each package you should delete its source and build -directories, unless 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. - -Now first check that your LFS environment variable is set up -properly: - -echo $LFS - -Make sure the output shows the path to your LFS partition's mount -point, which is /mnt/lfs if you -followed our example. +See testing. diff --git a/chapter05/kernel-headers.xml b/chapter05/kernel-headers.xml deleted file mode 100644 index d18ac0020..000000000 --- a/chapter05/kernel-headers.xml +++ /dev/null @@ -1,61 +0,0 @@ - - - %general-entities; -]> - -Linux-&linux-version; headers - - - -Linux -tools, headers - - - -<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 - -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 gcc can later find them. - -Prepare for the header installation with: - -make mrproper - -This ensures that the kernel tree is absolutely clean. The kernel team -recommends that this command be issued prior to each -kernel compilation. You shouldn't rely on the source tree being clean after -un-tarring. - -Create the include/linux/version.h file: - -make include/linux/version.h - -Create the platform-specific include/asm -symlink: - -make include/asm - -Install the platform-specific header files: - -mkdir /tools/glibc-kernheaders -cp -HR include/asm /tools/glibc-kernheaders -cp -R include/asm-generic /tools/glibc-kernheaders - -Finally, install the cross-platform kernel header files: - -cp -R include/linux /tools/glibc-kernheaders - - - - diff --git a/chapter05/linux-libc-headers.xml b/chapter05/linux-libc-headers.xml index a74ce26e3..bfbc637f3 100644 --- a/chapter05/linux-libc-headers.xml +++ b/chapter05/linux-libc-headers.xml @@ -24,12 +24,6 @@ Installation of Linux-Libc-Headers -For years it has been common practice to use so-called raw -kernel headers (straight from a kernel tarball) in /usr/include, 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. - Install the header files: cp -R include/asm-i386 /tools/include/asm diff --git a/chapter05/m4.xml b/chapter05/m4.xml index 5907e5cfc..0a4757497 100644 --- a/chapter05/m4.xml +++ b/chapter05/m4.xml @@ -12,7 +12,6 @@ tools -<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> -- cgit v1.2.3-54-g00ecf