diff options
Diffstat (limited to 'chapter04')
| -rw-r--r-- | chapter04/chapter04.xml | 505 |
1 files changed, 228 insertions, 277 deletions
diff --git a/chapter04/chapter04.xml b/chapter04/chapter04.xml index 79383efb0..07d13156e 100644 --- a/chapter04/chapter04.xml +++ b/chapter04/chapter04.xml @@ -1,333 +1,284 @@ -<chapter id="chapter-getting-materials" xreflabel="Chapter 4"> -<title>The materials: packages and patches</title> +<chapter id="chapter-preparation" xreflabel="Chapter 4"> +<title>Last preparations</title> <?dbhtml filename="chapter04.html" dir="chapter04"?> -<sect1 id="materials-introduction"> -<title>Introduction</title> -<?dbhtml filename="introduction.html" dir="chapter04"?> - -<para>Below is a list of packages you need to download for building a basic -Linux system. The listed version numbers correspond to versions of the -software that are <emphasis>known</emphasis> to work, and this book is -based upon them. Unless you are an experienced LFS builder, we highly -recommend not to try out newer versions, as the build commands for one -version may not work with a newer version. Also, there is often a good -reason for not using the latest version due to known problems that haven't -been worked around yet.</para> - -<para>All the URLs, when possible, refer to the project's page at -<ulink url="http://www.freshmeat.net/"/>. The Freshmeat -pages will give you easy access to the official download sites as well as -project websites, mailing lists, FAQs, changelogs and more.</para> - -<para>We can't guarantee that these download locations are always available. -In case a download location has changed since this book was published, please -try to google for the package. Should you remain unsuccessful with this, you -can consult the book's errata page at <ulink url="&lfs-root;lfs/print/"/> -or, better yet, try one of the alternative means of downloading listed on -<ulink url="&lfs-root;lfs/packages.html"/>.</para> - -<para>You'll need to store all the downloaded packages and patches somewhere -that is conveniently available throughout the entire build. You'll also need a -working directory in which to unpack the sources and build them. A scheme that -works well is to use <filename>$LFS/sources</filename> as the place to store -the tarballs and patches, <emphasis>and</emphasis> as a working directory. -This way everything you need will be located on the LFS partition and available -during all stages of the building process.</para> - -<para>So you may want to execute, as <emphasis>root</emphasis>, the following -command before starting your download session:</para> - -<screen><userinput>mkdir $LFS/sources</userinput></screen> - -<para>And make this directory writable (and sticky) for your normal user -- as -you won't do the downloading as <emphasis>root</emphasis>, we guess:</para> - -<screen><userinput>chmod a+wt $LFS/sources</userinput></screen> - -<!-- -<para>For your convenience the top of the list contains a link to a file -you can use with the <ulink url="http://wget.sunsite.dk">wget</ulink> -program. Using this file and the <command>wget</command> program will -make it easy to download all the files at once, rather than downloading each -and every individual file manually.</para> ---> +<sect1 id="prepare-aboutlfs"> +<title>About $LFS</title> +<?dbhtml filename="aboutlfs.html" dir="chapter04"?> -</sect1> - - -<sect1 id="materials-packages"> -<title>All the packages</title> -<?dbhtml filename="packages.html" dir="chapter04"?> - -<para>Download or otherwise obtain the following packages:</para> - -<literallayout> -Autoconf (&autoconf-version;) - &autoconf-size;: -<ulink url="http://freshmeat.net/projects/autoconf/"/> - -Automake (&automake-version;) - &automake-size;: -<ulink url="http://freshmeat.net/projects/automake/"/> - -Bash (&bash-version;) - &bash-size;: -<ulink url="http://freshmeat.net/projects/gnubash/"/> - -Binutils (&binutils-version;) - &binutils-size;: -<ulink url="http://freshmeat.net/projects/binutils/"/> - -Bison (&bison-version;) - &bison-size;: -<ulink url="http://freshmeat.net/projects/bison/"/> - -Bzip2 (&bzip2-version;) - &bzip2-size;: -<ulink url="http://freshmeat.net/projects/bzip2/"/> - -Coreutils (&coreutils-version;) - &coreutils-size;: -<ulink url="http://freshmeat.net/projects/coreutils/"/> - -DejaGnu (&dejagnu-version;) - &dejagnu-size;: -<ulink url="http://freshmeat.net/projects/dejagnu/"/> - -Diffutils (&diffutils-version;) - &diffutils-size;: -<ulink url="http://freshmeat.net/projects/diffutils/"/> - -E2fsprogs (&e2fsprogs-version;) - &e2fsprogs-size;: -<ulink url="http://freshmeat.net/projects/e2fsprogs/"/> - -Ed (&ed-version;) - &ed-size;: -<ulink url="http://freshmeat.net/projects/ed/"/> - -Expect (&expect-version;) - &expect-size;: -<ulink url="http://freshmeat.net/projects/expect/"/> - -File (&file-version;) - &file-size;: -- <emphasis>(see Note 1 below)</emphasis> -<ulink url="http://freshmeat.net/projects/file/"/> - -Findutils (&findutils-version;) - &findutils-size;: -<ulink url="http://freshmeat.net/projects/findutils/"/> - -Flex (&flex-version;) - &flex-size;: -<ulink url="ftp://ftp.gnu.org/gnu/non-gnu/flex/"/> - -Gawk (&gawk-version;) - &gawk-size;: -<ulink url="http://freshmeat.net/projects/gnuawk/"/> - -GCC (&gcc-2953-version;) - &gcc-2953-size;: -<ulink url="http://freshmeat.net/projects/gcc/"/> - -GCC-core (&gcc-version;) - &gcc-core-size;: -<ulink url="http://freshmeat.net/projects/gcc/"/> - -GCC-g++ (&gcc-version;) - &gcc-gpp-size;: -<ulink url="http://freshmeat.net/projects/gcc/"/> +<para>Throughout this book the environment variable LFS will be used several +times. It is paramount that this variable is always defined. It should be set +to the mount point you chose for your LFS partition. Check that your LFS +variable is set up properly with:</para> -GCC-testsuite (&gcc-version;) - &gcc-testsuite-size;: -<ulink url="http://freshmeat.net/projects/gcc/"/> +<screen><userinput>echo $LFS</userinput></screen> -Gettext (&gettext-version;) - &gettext-size;: -<ulink url="http://freshmeat.net/projects/gettext/"/> +<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. If the output is wrong, you can always set the variable +with:</para> -Glibc (&glibc-version;) - &glibc-size;: -- <emphasis>(see Note 2 below)</emphasis> -<ulink url="http://freshmeat.net/projects/glibc/"/> +<screen><userinput>export LFS=/mnt/lfs</userinput></screen> -Grep (&grep-version;) - &grep-size;: -<ulink url="http://freshmeat.net/projects/grep/"/> +<para>Having this variable set means that if you are told to run a command like +<userinput>mkdir $LFS/tools</userinput>, you can type it literally. Your shell +will replace "$LFS" with "/mnt/lfs" (or whatever you set the variable to) when +it processes the command line.</para> -Groff (&groff-version;) - &groff-size;: -<ulink url="http://freshmeat.net/projects/groff/"/> - -Grub (&grub-version;) - &grub-size;: -<ulink url="ftp://alpha.gnu.org/pub/gnu/grub/"/> - -Gzip (&gzip-version;) - &gzip-size;: -<ulink url="ftp://alpha.gnu.org/gnu/gzip/"/> - -Inetutils (&inetutils-version;) - &inetutils-size;: -<ulink url="http://freshmeat.net/projects/inetutils/"/> - -Kbd (&kbd-version;) - &kbd-size;: -<ulink url="http://freshmeat.net/projects/kbd/"/> - -Less (&less-version;) - &less-size;: -<ulink url="http://freshmeat.net/projects/less/"/> - -LFS-Bootscripts (&bootscripts-version;) - &bootscripts-size;: -<ulink url="&http-down;lfs-bootscripts-&bootscripts-version;.tar.bz2"/> - -Lfs-Utils (&lfs-utils-version;) - &lfs-utils-size;: -<ulink url="&lfs-root;~winkie/downloads/lfs-utils/"/> - -Libtool (&libtool-version;) - &libtool-size;: -<ulink url="http://freshmeat.net/projects/libtool/"/> - -Linux (&kernel-version;) - &kernel-size;: -<ulink url="http://freshmeat.net/projects/linux/"/> - -M4 (&m4-version;) - &m4-size;: -<ulink url="http://freshmeat.net/projects/gnum4/"/> +</sect1> -Make (&make-version;) - &make-size;: -<ulink url="http://freshmeat.net/projects/gnumake/"/> -Make_devices (&makedev-version;) - &makedev-size;: -<ulink url="&lfs-root;~alex/make_devices-&makedev-version;.bz2"/> +<sect1 id="prepare-creatingtoolsdir"> +<title>Creating the $LFS/tools directory</title> +<?dbhtml filename="creatingtoolsdir.html" dir="chapter05"?> -Man (&man-version;) - &man-size;: -<ulink url="http://freshmeat.net/projects/man/"/> +<para>All programs compiled in this chapter will be installed under <filename +class="directory">$LFS/tools</filename> to keep them separate from the +programs compiled in the next chapter. The programs compiled here are only +temporary tools and won't be a part of the final LFS system and by keeping them +in a separate directory, we can later easily throw them away.</para> -Man-pages (&man-pages-version;) - &man-pages-size;: -<ulink url="http://freshmeat.net/projects/man-pages/"/> +<para>Later on you might wish to search through the binaries of your system to +see what files they make use of or link against. To make this searching easier +you may want to choose a unique name for the directory in which the temporary +tools are stored. Instead of the simple "tools" you could use something like +"tools-for-lfs". However, you'll need to be careful to adjust all references to +"tools" throughout the book -- including those in any patches, notably the +GCC Specs Patch.</para> -Modutils (&modutils-version;) - &modutils-size;: -<ulink url="http://freshmeat.net/projects/modutils/"/> +<para>Create the required directory by running the following:</para> -Ncurses (&ncurses-version;) - &ncurses-size;: -<ulink url="http://freshmeat.net/projects/ncurses/"/> +<screen><userinput>mkdir $LFS/tools</userinput></screen> -Net-tools (&net-tools-version;) - &net-tools-size;: -<ulink url="http://freshmeat.net/projects/net-tools/"/> +<para>The next step is to create a <filename>/tools</filename> symlink on +your host system. It will point to the directory we just created on the LFS +partition:</para> -Patch (&patch-version;) - &patch-size;: -<ulink url="http://freshmeat.net/projects/patch/"/> +<screen><userinput>ln -s $LFS/tools /</userinput></screen> -Perl (&perl-version;) - &perl-size;: -<ulink url="http://freshmeat.net/projects/perl/"/> +<note><para>The above command is correct. The <command>ln</command> command +has a few syntactic variations, so be sure to check the info page before +reporting what you may think is an error.</para></note> -Procinfo (&procinfo-version;) - &procinfo-size;: -<ulink url="http://freshmeat.net/projects/procinfo/"/> +<para>The created symlink enables us to compile our toolchain so that it always +refers to <filename>/tools</filename>, meaning that the compiler, assembler +and linker will work both in this chapter (when we are still using some tools +from the host) <emphasis>and</emphasis> in the next (when we are chrooted to +the LFS partition).</para> -Procps (&procps-version;) - &procps-size;: -<ulink url="http://freshmeat.net/projects/procps/"/> +</sect1> -Psmisc (&psmisc-version;) - &psmisc-size;: -<ulink url="http://freshmeat.net/projects/psmisc/"/> -Sed (&sed-version;) - &sed-size;: -<ulink url="http://freshmeat.net/projects/sed/"/> +<sect1 id="prepar-addinguser"> +<title>Adding the user lfs</title> +<?dbhtml filename="addinguser.html" dir="chapter05"?> -Shadow (&shadow-version;) - &shadow-size;: -<ulink url="http://freshmeat.net/projects/shadow/"/> +<para>When logged in as <emphasis>root</emphasis>, making a single mistake +can damage or even wreck your system. Therefore we recommend that you +build the packages in this chapter as an unprivileged user. You could +of course use your own user name, but to make it easier to set up a clean +work environment we'll create a new user <emphasis>lfs</emphasis> and +use this one during the installation process. As <emphasis>root</emphasis>, +issue the following command to add the new user:</para> -Sysklogd (&sysklogd-version;) - &sysklogd-size;: -<ulink url="http://freshmeat.net/projects/sysklogd/"/> +<screen><userinput>useradd -s /bin/bash -m -k /dev/null lfs</userinput></screen> -Sysvinit (&sysvinit-version;) - &sysvinit-size;: -<ulink url="http://freshmeat.net/projects/sysvinit/"/> +<para>The meaning of the switches:</para> -Tar (&tar-version;) - &tar-size;: -<ulink url="ftp://alpha.gnu.org/gnu/tar/"/> +<itemizedlist> +<listitem><para><userinput>-s /bin/bash</userinput>: This makes +<userinput>bash</userinput> the default shell for user +<emphasis>lfs</emphasis>.</para></listitem> -Tcl (&tcl-version;) - &tcl-size;: -<ulink url="http://freshmeat.net/projects/tcltk/"/> +<listitem><para><userinput>-m -k /dev/null</userinput>: These create a home +directory for <emphasis>lfs</emphasis>, while preventing the files from a +possible <filename>/etc/skel</filename> being copied into it.</para></listitem> +</itemizedlist> -Texinfo (&texinfo-version;) - &texinfo-size;: -<ulink url="http://freshmeat.net/projects/texinfo/"/> +<para>If you want to be able to log in as <emphasis>lfs</emphasis>, then give +this new user a password:</para> -Util-linux (&util-linux-version;) - &util-linux-size;: -<ulink url="http://freshmeat.net/projects/util-linux/"/> +<screen><userinput>passwd lfs</userinput></screen> -Vim (&vim-version;) - &vim-size;: -<ulink url="http://freshmeat.net/projects/vim/"/> +<para>Now grant this new user <emphasis>lfs</emphasis> full access to +<filename class="directory">$LFS/tools</filename> by giving it ownership +of the directory:</para> -Zlib (&zlib-version;) - &zlib-size;: -<ulink url="http://freshmeat.net/projects/zlib/"/> +<screen><userinput>chown lfs $LFS/tools</userinput></screen> -Total size of these packages: &all-size-mb; -</literallayout> +<para>If you made a separate working directory as suggested, give user +<emphasis>lfs</emphasis> ownership of this directory too:</para> -<note><para>1) File (&file-version;) may not be available by the time you read -this. The site admins of the master download location are known to occasionally -remove old versions when new ones are released. Please refer to the -<xref linkend="ch-system-file"/> section for an alternate download -location.</para></note> +<screen><userinput>chown lfs $LFS/sources</userinput></screen> -<note><para>2) As of this writing, the Glibc maintainers have decided in their -wisdom not to make available new release tarballs for download. The only way to -obtain the current Glibc release from pristine upstream sources is to pull it -from the Glibc CVS repository. The following commands will download the current -release and make a tarball from it:</para> +<para>Next, login as user <emphasis>lfs</emphasis>. This can be done via a +virtual console, through a display manager, or with the following substitute +user command:</para> -<screen><userinput>cvs -z 9 -d :pserver:anoncvs@sources.redhat.com:/cvs/glibc \ - export -d &glibc-dir; -D "2003-12-02 UTC" libc -tar jcvf &glibc-package; &glibc-dir;</userinput></screen> +<screen><userinput>su - lfs</userinput></screen> -<para>Alternatively, we've made our own tarball available which you can -download courtesy of the generous LFS mirror sites. Please refer to the -<xref linkend="ch-tools-glibc"/> section for the download links.</para></note> +<para>The "<command>-</command>" instructs <command>su</command> to start a +<emphasis>login</emphasis> shell.</para> </sect1> -<sect1 id="materials-patches"> -<title>Needed patches</title> -<?dbhtml filename="patches.html" dir="chapter04"?> +<sect1 id="prepare-settingenvironment"> +<title>Setting up the environment</title> +<?dbhtml filename="settingenvironment.html" dir="chapter05"?> + +<para>We're going to set up a good working environment by creating two new +startup files for the <command>bash</command> shell. While logged in as +user <emphasis>lfs</emphasis>, issue the following command to create a new +<filename>.bash_profile</filename>:</para> + +<screen><userinput>cat > ~/.bash_profile << "EOF"</userinput> +exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash +<userinput>EOF</userinput></screen> + +<para>Normally, when you log on as user <emphasis>lfs</emphasis>, +the initial shell is a <emphasis>login</emphasis> shell which reads the +<filename>/etc/profile</filename> of your host (probably containing some +settings of environment variables) and then <filename>.bash_profile</filename>. +The <command>exec env -i ... /bin/bash</command> command in the latter file +replaces the running shell with a new one with a completely empty environment, +except for the HOME, TERM and PS1 variables. This ensures that no unwanted and +potentially hazardous environment variables from the host system leak into our +build environment. The technique used here is a little strange, but it achieves +the goal of enforcing a clean environment.</para> + +<para>The new instance of the shell is a <emphasis>non-login</emphasis> shell, +which doesn't read the <filename>/etc/profile</filename> or +<filename>.bash_profile</filename> files, but reads the +<filename>.bashrc</filename> file instead. Create this latter file now:</para> + +<screen><userinput>cat > ~/.bashrc << "EOF"</userinput> +set +h +umask 022 +LFS=/mnt/lfs +LC_ALL=POSIX +PATH=/tools/bin:/bin:/usr/bin +export LFS LC_ALL PATH +<userinput>EOF</userinput></screen> + +<para>The <command>set +h</command> command turns off +<command>bash</command>'s hash function. Normally hashing is a useful +feature: <command>bash</command> uses a hash table to remember the +full pathnames of executable files to avoid searching the PATH time and time +again to find the same executable. However, we'd like the new tools to be +used as soon as they are installed. By switching off the hash function, our +"interactive" commands (<command>make</command>, +<command>patch</command>, <command>sed</command>, +<command>cp</command> and so forth) will always use +the newest available version during the build process.</para> + +<para>Setting the user file-creation mask to 022 ensures that newly created +files and directories are only writable for their owner, but readable and +executable for anyone.</para> + +<para>The LFS variable should of course be set to the mount point you +chose.</para> + +<para>The LC_ALL variable controls the localization of certain programs, +making their messages follow the conventions of a specified country. If your +host system uses a version of Glibc older than 2.2.4, +having LC_ALL set to something other than "POSIX" or "C" during this chapter +may cause trouble if you exit the chroot environment and wish to return later. +By setting LC_ALL to "POSIX" (or "C", the two are equivalent) we ensure that +everything will work as expected in the chroot environment.</para> + +<para>We prepend <filename>/tools/bin</filename> to the standard PATH so +that, as we move along through this chapter, the tools we build will get used +during the rest of the building process.</para> + +<para>Finally, to have our environment fully prepared for building the +temporary tools, source the just-created profile:</para> + +<screen><userinput>source ~/.bash_profile</userinput></screen> -<para>Besides all those packages, you'll also need several patches. These -correct tiny mistakes in the packages that should be fixed by the maintainer, -or just make some small modifications to bend things our way. You'll need the -following:</para> - -<literallayout> -Bash Patch - &bash-patch-size;: -<ulink url="&patches-root;&bash-patch;"/> - -Bison Attribute Patch - &bison-patch-size;: -<ulink url="&patches-root;&bison-patch;"/> - -Coreutils Hostname Patch - &coreutils-hostname-patch-size;: -<ulink url="&patches-root;&coreutils-hostname-patch;"/> - -Coreutils Posixver Patch - &coreutils-posixver-patch-size;: -<ulink url="&patches-root;&coreutils-posixver-patch;"/> - -Coreutils Uname Patch - &coreutils-uname-patch-size;: -<ulink url="&patches-root;&coreutils-uname-patch;"/> - -Ed Mkstemp Patch - &ed-patch-size;: -<ulink url="&patches-root;&ed-patch;"/> - -Expect Spawn Patch - &expect-patch-size;: -<ulink url="&patches-root;&expect-patch;"/> +</sect1> -GCC No-Fixincludes Patch - &gcc-nofixincludes-patch-size;: -<ulink url="&patches-root;&gcc-nofixincludes-patch;"/> -GCC Specs Patch - &gcc-specs-patch-size;: -<ulink url="&patches-root;&gcc-specs-patch;"/> +<sect1 id="prepare-aboutsbus"> +<title>About SBUs</title> +<?dbhtml filename="aboutsbus.html" dir="chapter04"?> -GCC-2 Patch - &gcc-2953-patch-size;: -<ulink url="&patches-root;&gcc-2953-patch;"/> +<para>Most people would like to know beforehand how long it approximately +takes to compile and install each package. But "Linux from Scratch" is built +on so many different systems, it is not possible to give actual times that are +anywhere near accurate: the biggest package (Glibc) won't take more than +twenty minutes on the fastest systems, but will take something like three days +on the slowest -- no kidding. So instead of giving actual times, we've come up +with the idea of using the <emphasis>Static Binutils Unit</emphasis> +(abbreviated to <emphasis>SBU</emphasis>).</para> -GCC-2 No-Fixincludes Patch - &gcc-2953-no-fixinc-patch-size;: -<ulink url="&patches-root;&gcc-2953-no-fixinc-patch;"/> +<para>It works like this: the first package you compile in this book is the +statically linked Binutils in <xref linkend="chapter-temporary-tools"/>, and the time it +takes to compile this package is what we call the "Static Binutils Unit" or +"SBU". All other compile times will be expressed relative to this time.</para> -GCC-2 Return-Type Patch - &gcc-2953-returntype-fix-patch-size;: -<ulink url="&patches-root;&gcc-2953-returntype-fix-patch;"/> +<para>For example, the time it takes to build the static version of GCC is +&gcc-time-tools-pass1;s. This means that if on your system it took 10 minutes +to compile and install the static Binutils, then you know it will take +approximately 45 minutes to build the static GCC. Fortunately, most build times +are much shorter than the one of Binutils.</para> -Inetutils No-Server-Man-Pages Patch - &inetutils-no-server-man-pages-patch-size;: -<ulink url="&patches-root;&inetutils-no-server-man-pages-patch;"/> +<para>Note that if the system compiler on your host is GCC-2 based, the SBUs +listed may end up being somewhat understated. This is because the SBU is based +on the very first package, compiled with the old GCC, while the rest of the +system is compiled with the newer GCC-&gcc-version; which is known to be +approximately 30% slower.</para> -Kbd More-Programs Patch - &kbd-patch-size;: -<ulink url="&patches-root;&kbd-patch;"/> +<para>Also note that SBUs don't work well for SMP-based machines. But if you're +so lucky as to have multiple processors, chances are that your system is so fast +that you won't mind.</para> -Man 80-Columns Patch - &man-80cols-patch-size;: -<ulink url="&patches-root;&man-80cols-patch;"/> +<para>If you wish to see actual timings for specific machines, have a look at +<ulink url="&lfs-root;~bdubbs/"/>.</para> -Net-tools Mii-Tool-Gcc33 Patch - &net-tools-mii-patch-size;: -<ulink url="&patches-root;&net-tools-mii-patch;"/> +</sect1> -Perl Libc Patch - &perl-libc-patch-size;: -<ulink url="&patches-root;&perl-libc-patch;"/> -</literallayout> -<para>In addition to the above required patches, there exist a number of -optional ones created by the LFS community. Most of these solve slight -problems, or enable some functionality that's not enabled by default. -Feel free to examine the patches database, located at <ulink -url="&lfs-root;patches/"/>, and pick any additional patches you wish to -use.</para> +<sect1 id="prepare-abouttestsuites"> +<title>About the test suites</title> +<?dbhtml filename="abouttestsuites.html" dir="chapter04"?> + +<para>Most packages provide a test suite. Running the test suite for a newly +built package is generally a good idea, as it can provide a nice sanity check +that everything compiled correctly. A test suite that passes its set of checks +usually proves that the package is functioning as the developer intended. It +does not, however, guarantee that the package is totally bug free.</para> + +<para>Some test suites are more important than others. For example, the test +suites for the core toolchain packages -- GCC, Binutils, and Glibc -- are of +the utmost importance due to their central role in a properly functioning +system. But be warned, the test suites for GCC and Glibc can take a very long +time to complete, especially on slower hardware.</para> + +<note><para>Experience has shown us that there is little to be gained from running +the test suites in <xref linkend="chapter-temporary-tools"/>. There can be no +escaping the fact that the host system always exerts some influence on the +tests in that chapter, often causing weird and inexplicable failures. Not only +that, the tools built in <xref linkend="chapter-temporary-tools"/> are +temporary and eventually discarded. For the average reader of this book we +recommend <emphasis>not</emphasis> to run the test suites in <xref +linkend="chapter-temporary-tools"/>. The instructions for running those test +suites are still provided for the benefit of testers and developers, but they +are strictly optional for everyone else.</para></note> + +<para>A common problem when running the test suites for Binutils and GCC is +running out of pseudo terminals (PTYs for short). The symptom is a very high +number of failing tests. This can happen for several reasons, but the most +likely cause is that the host system doesn't have the +<emphasis>devpts</emphasis> file system set up correctly. We'll discuss this in +more detail later on in <xref linkend="chapter-temporary-tools"/>.</para> + +<para>Sometimes package test suites will give false failures. You can +consult the LFS Wiki at <ulink url="&wiki-root;"/> to verify that these +failures are normal. This applies to all tests throughout the book.</para> </sect1> -</chapter> +</chapter> |