Linux From Scratch Version 5.0 Gerard Beekmans Copyright © 1999-2003 Gerard Beekmans This book describes the process of creating a Linux system from scratch, using nothing but the sources of the required software. Copyright (c) 1999-2003, Gerard Beekmans All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:   * Redistributions in any form must retain the above copyright notice, this list of conditions and the following disclaimer.   * Neither the name of "Linux From Scratch" nor the names of its contributors may be used to endorse or promote products derived from this material without specific prior written permission.   * Any material derived from Linux From Scratch must contain a reference to the "Linux From Scratch" project. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. ----------------------------------------------------------------------------- ----------------------------------------------------------------------------- Dedication This book is dedicated to my loving and supportive wife Beverly Beekmans. Table of Contents Preface 1. Foreword 2. Audience 3. Prerequisites 4. Structure I. Part I - Introduction 1. Introduction 2. Important information II. Part II - Preparing for the build 3. Preparing a new partition 4. The materials: packages and patches 5. Constructing a temporary system III. Part III - Building the LFS system 6. Installing basic system software 7. Setting up system boot scripts 8. Making the LFS system bootable 9. The End IV. Part IV - Appendices A. Package descriptions and dependencies B. Index of programs and library files ----------------------------------------------------------------------------- Preface ----------------------------------------------------------------------------- 1. Foreword Having used a number of different Linux distributions, I was never fully satisfied with any of them. I didn't like the arrangement of the bootscripts. I didn't like the way certain programs were configured by default. Much more of that sort of thing bothered me. Finally I realized that if I wanted full satisfaction from my Linux system I would have to build my own system from scratch, using only the source code. I resolved not to use pre-compiled packages of any kind, nor CD-ROM or boot disk that would install some basic utilities. I would use my current Linux system to develop my own. This wild idea seemed very difficult at the time and often seemed an impossible task. After sorting out all kinds of problems, such as dependencies and compile-time errors, a custom-built Linux system was created that was fully operational. I called this system a Linux From Scratch system, or LFS for short. I hope you will have a great time working on your own LFS! --  Gerard Beekmans gerard@linuxfromscratch.org ----------------------------------------------------------------------------- 2. Audience ----------------------------------------------------------------------------- 2.1. Who would want to read this book There are many reasons why somebody would want to read this book. The principal reason being to install a Linux system straight from the source code. A question many people raise is "Why go through all the hassle of manually building a Linux system from scratch when you can just download and install an existing one?". That is a good question and is the impetus for this section of the book. One important reason for LFS's existence is to help people learn how a Linux system works from the inside out. Building an LFS system helps demonstrate to you what makes Linux tick, how things work together and depend on each other. One of the best things that this learning experience provides is the ability to customize Linux to your own tastes and needs. A key benefit of LFS is that you have more control of your system without relying on someone else's Linux implementation. With LFS, you are in the driver's seat and dictate every aspect of your system, such as the directory layout and bootscript setup. You also dictate where, why and how programs are installed. Another benefit of LFS is the ability to create a very compact Linux system. When installing a regular distribution, you are usually forced to install several programs which you are likely never to use. They're just sitting there wasting precious disk space (or worse, CPU cycles). It isn't difficult to build an LFS system less than 100 MB. Does that still sound like a lot? A few of us have been working on creating a very small embedded LFS system. We successfully built a system that was just enough to run the Apache web server with approximately 8MB of disk space used. Further stripping could bring that down to 5 MB or less. Try that with a regular distribution. We could compare distributed Linux to a hamburger you buy at a fast-food restaurant -- you have no idea what you are eating. LFS, on the other hand, doesn't give you a hamburger, but the recipe to make a hamburger. This allows you to review it, to omit unwanted ingredients, and to add your own ingredients which enhance the flavor of your burger. When you are satisfied with the recipe, you go on to preparing it. You make it just the way you like it: broil it, bake it, deep-fry it, barbecue it, or eat it tar-tar (raw). Another analogy that we can use is that of comparing LFS with a finished house. LFS will give you the skeletal plan of a house, but it's up to you to build it. You have the freedom to adjust your plans as you go. One last advantage of a custom built Linux system is security. By compiling the entire system from source code, you are empowered to audit everything and apply all the security patches you feel are needed. You don't have to wait for somebody else to compile binary packages that fix a security hole. Unless you examine the patch and implement it yourself you have no guarantee that the new binary package was built correctly and actually fixes the problem (adequately). There are too many good reasons to build your own LFS system for them all to be listed here. This section is only the tip of the iceberg. As you continue in your LFS experience, you will find on your own the power that information and knowledge truly bring. ----------------------------------------------------------------------------- 2.2. Who would not want to read this book There are probably some who, for whatever reason, would feel that they do not want to read this book. If you do not wish to build your own Linux system from scratch, then you probably don't want to read this book. Our goal is to help you build a complete and usable foundation-level system. If you only want to know what happens while your computer boots, then we recommend the "From Power Up To Bash Prompt" HOWTO. The HOWTO builds a bare system which is similar to that of this book, but it focuses strictly on creating a system capable of booting to a BASH prompt. While you decide which to read, consider your objective. If you wish to build a Linux system while learning a bit along the way, then this book is probably your best choice. If your objective is strictly educational and you do not have any plans for your finished system, then the "From Power Up To Bash Prompt" HOWTO is probably a better choice. The "From Power Up To Bash Prompt" HOWTO is located at [http:// axiom.anu.edu.au/~okeefe/p2b/] http://axiom.anu.edu.au/~okeefe/p2b/ or on The Linux Documentation Project's website at [http://www.tldp.org/HOWTO/ From-PowerUp-To-Bash-Prompt-HOWTO.html] http://www.tldp.org/HOWTO/ From-PowerUp-To-Bash-Prompt-HOWTO.html. ----------------------------------------------------------------------------- 3. Prerequisites This book assumes that its reader has a good deal of knowledge about using and installing Linux software. Before you begin building your LFS system, you should read the following HOWTOs:   * Software-Building-HOWTO This is a comprehensive guide to building and installing "generic" UNIX software distributions under Linux. This HOWTO is available at [http:// www.tldp.org/HOWTO/Software-Building-HOWTO.html] http://www.tldp.org/ HOWTO/Software-Building-HOWTO.html.   * The Linux Users' Guide This guide covers the usage of assorted Linux software and is available at [http://espc22.murdoch.edu.au/~stewart/guide/guide.html] http:// espc22.murdoch.edu.au/~stewart/guide/guide.html.   * The Essential Pre-Reading Hint This is an LFS Hint written specifically for new users of Linux. It is mostly a list of links to excellent sources of information on a wide range of topics. Any person attempting to install LFS, should at least have an understanding of many of the topics in this hint. It is available at [http://www.linuxfromscratch.org/hints/downloads/files/ essential_prereading.txt] http://www.linuxfromscratch.org/hints/downloads /files/essential_prereading.txt ----------------------------------------------------------------------------- 4. Structure This book is divided into the following four parts: ----------------------------------------------------------------------------- 4.1. Part I - Introduction Part I explains a few important things on how to proceed with the installation, and gives meta information about the book (version, changelog, acknowledgments, associated mailing lists, and so on). ----------------------------------------------------------------------------- 4.2. Part II - Preparing for the build Part II describes how to prepare for the building process: making a partition, downloading the packages, and compiling temporary tools. ----------------------------------------------------------------------------- 4.3. Part III - Building the LFS system Part III guides you through the building of the LFS system: compiling and installing all the packages one by one, setting up the boot scripts, and installing the kernel. The resulting basic Linux system is the foundation upon which you can build other software, to extend your system in the way you like. ----------------------------------------------------------------------------- 4.4. Part IV - Appendices Part IV consists of two appendices. The first is an alphabetical list of all the packages that are installed -- for each package giving its official download location, its contents, and its installation dependencies. The second appendix lists all the programs and libraries installed by these packages in alphabetical order, so you can easily find out to which package a certain program or library belongs. (Much of the first appendix is integrated into Parts II and III. This enlarges the book somewhat, but we believe it makes for easier reading. Now you don't have to keep referencing the appendix while doing the installation. This going back and forth would be a real chore, especially if you're reading a plain text version of the book.) I. Part I - Introduction Table of Contents 1. Introduction 1.1. How things are going to be done 1.2. Conventions used in this book 1.3. Book version 1.4. Changelog 1.5. Resources 1.6. Acknowledgments 2. Important information 2.1. About $LFS 2.2. About SBUs 2.3. About the test suites 2.4. How to ask for help ----------------------------------------------------------------------------- Chapter 1. Introduction ----------------------------------------------------------------------------- 1.1. How things are going to be done You are going to build your LFS system by using a previously installed Linux distribution (such as Debian, Mandrake, Red Hat, or SuSE). This existing Linux system (the host) will be used as a starting point, because you will need programs like a compiler, linker and shell to build the new system. Normally all the required tools are available if you selected "development" as one of the options when you installed your distribution. In Chapter 3 you will first create a new Linux native partition and file system, the place where your new LFS system will be compiled and installed. Then in Chapter 4 you download all the packages and patches required to build an LFS system, and store them on the new file system. Chapter 5 then discusses the installation of a number of packages that will form the basic development suite (or toolchain) which is used to build the actual system in Chapter 6. Some of these packages are needed to resolve circular dependencies -- for example, to compile a compiler you need a compiler. The first thing to be done in Chapter 5 is build a first pass of the toolchain, made up of Binutils and GCC. The programs from these packages will be linked statically in order for them to be usable independently of the host system. The second thing to do is build Glibc, the C library. Glibc will be compiled by the toolchain programs we just built in the first pass. The third thing to do is build a second pass of the toolchain. This time the toolchain will be dynamically linked against the newly built Glibc. The remaining Chapter 5 packages are all built using this second pass toolchain and dynamically linked against the new host-independent Glibc. When this is done, the LFS installation process will no longer depend on the host distribution, with the exception of the running kernel. You may be thinking that "this seems like a lot of work, just to get away from my host distribution". Well, a full technical explanation is provided at the start of Chapter 5, including some notes on the differences between statically and dynamically linked programs. In Chapter 6 your real LFS system will be built. The chroot (change root) program is used to enter a virtual environment and start a new shell whose root directory will be set to the LFS partition. This is very similar to rebooting and instructing the kernel to mount the LFS partition as the root partition. The reason that you don't actually reboot, but instead chroot, is that creating a bootable system requires additional work which isn't necessary just yet. But the major advantage is that chrooting allows you to continue using the host while LFS is being built. While waiting for package compilation to complete, you can simply switch to a different VC (Virtual Console) or X desktop and continue using the computer as you normally would. To finish the installation, the bootscripts are set up in Chapter 7, the kernel and bootloader are set up in Chapter 8, and Chapter 9 contains some pointers to help you after you finish the book. Then, finally, you're ready to reboot your computer into your new LFS system. This is the process in a nutshell. Detailed information on the steps you will take are discussed in the chapters and package descriptions as you progress through them. If something isn't completely clear now, don't worry, everything will fall into place soon. Please read Chapter 2 carefully as it explains a few important things you should be aware of before you begin to work through Chapter 5 and beyond. ----------------------------------------------------------------------------- 1.2. Conventions used in this book To make things easy to follow, there are a number of conventions used throughout the book. Following are some examples: ./configure --prefix=/usr This form of text is designed to be typed exactly as seen unless otherwise noted in the surrounding text. It is also used in the explanation sections to identify which of the commands is being referenced. install-info: unknown option `--dir-file=/mnt/lfs/usr/info/dir' This form of text (fixed width text) is showing screen output, probably as the result of commands issued, and is also used to show filenames, such as /etc/ld.so.conf. Emphasis This form of text is used for several purposes in the book, mainly to emphasize important points, and to give examples of what to type. [http://www.linuxfromscratch.org/] http://www.linuxfromscratch.org/ This form of text is used for hyperlinks, both within the book and to external pages such as HOWTOs, download locations and websites. cat > $LFS/etc/group << "EOF" root:x:0: bin:x:1: ...... EOF This type of section is used mainly when creating configuration files. The first command tells the system to create the file $LFS/etc/group from whatever is typed on the following lines until the sequence EOF is encountered. Therefore, this whole section is generally typed as seen. ----------------------------------------------------------------------------- 1.3. Book version This is version 5.0 of the Linux From Scratch book, dated November 5th, 2003. If this book is more than two months old, a newer and better version is probably already available. To find out, check one of the mirrors listed on [http://www.linuxfromscratch.org/] http://www.linuxfromscratch.org/. ----------------------------------------------------------------------------- 1.4. Changelog 5.0 - November 5th, 2003   * Upgraded to:   + automake-1.7.6   + bash-2.05b   + binutils-2.14   + e2fsprogs-1.34   + file-4.04   + findutils-4.1.20   + gawk-3.1.3   + gcc-3.3.1   + gettext-0.12.1   + glibc-2.3.2   + glibc-2.3.2-sscanf-1.patch   + grep-2.5.1   + groff-1.19   + gzip-1.3.5   + less-381   + lfs-bootscripts-1.12   + libtool-1.5   + linux-2.4.22   + man-1.5m2   + man-1.5m2-80cols.patch   + man-1.5m2-manpath.patch   + man-1.5m2-pager.patch   + man-pages-1.60   + modutils-2.4.25   + procps-3.1.11   + procps-3.1.11.patch   + psmisc-21.3   + sed-4.0.7   + sysvinit-2.85   + tar-1.13.25   + texinfo-4.6   + util-linux-2.12   + vim-6.2   * Added:   + bash-2.05b-2.patch   + bison-1.875-attribute.patch   + coreutils-5.0   + coreutils-5.0-uname.patch   + coreutils-5.0-hostname-2.patch   + dejagnu-1.4.3   + expect-5.39.0   + expect-5.39.0.patch   + gawk-3.1.3.patch   + gcc-2.95.3   + gcc-2.95.3-2.patch   + gcc-2.95.3-no-fixinc.patch   + gcc-2.95.3-returntype-fix.patch   + gcc-3.3.1-no_fixincludes-2.patch   + gcc-3.3.1-specs-2.patch   + gcc-3.3.1-suppress-libiberty.patch   + grub-0.93   + grub-0.93-gcc33-1.patch   + inetutils-1.4.2   + lfs-utils-0.3   + ncurses-5.3-etip-2.patch   + ncurses-5.3-vsscanf.patch   + perl-5.8.0-libc-3.patch   + shadow-4.0.3-newgroup-fix.patch   + tcl-8.4.4   + zlib-1.1.4-vsnprintf.patch   * Removed:   + bin86-0.16.3   + fileutils-4.1   + fileutils-4.1.patch   + findutils-4.1-segfault.patch   + findutils-4.1.patch   + glibc-2.3.1-libnss.patch   + glibc-2.3.1-root-perl.patch   + gzip-1.2.4b.patch   + lilo-22.2   + netkit-base-0.17   + sh-utils-2.0   + sh-utils-2.0.patch   + sh-utils-2.0-hostname.patch   + tar-1.13.patch   + textutils-2.1   + vim-6.1.patch   * November 2nd, 2003 [alex]: Appendix A - Commented out all the "last checked against" lines.   * October 28th, 2003 [greg]: Strengthened the seds in "Locking in Glibc" and "Re-adjusting the toolchain" sections.   * October 26th, 2003 [greg]: Chapter 6 - Glibc: Added command to create / etc/ld.so.conf to match Chapter 5 Glibc. Closes bug 700.   * October 24th, 2003 [alex]: Appendix A - Changed the dependencies to the concise format, based on Tushar's post .   * October 23rd, 2003 [gerard] Chapter 9 - The End: Changed the /etc/lfs filename to /etc/lfs-release to be more consistent with other distributions out there.   * October 23rd, 2003 [alex]: Changed most of the "Chapter" references to proper "xref" cross references .   * October 22nd, 2003 [alex]: Chapter 6 - Gawk and Shadow: Adjusted the text. And added some markup elsewhere.   * October 22nd, 2003 [alex]: Chapter 6 - Entering the chroot environment: Dropped the set +h command, as it is pointless there: it's redone several sections later.   * October 15th, 2003 [greg]: Chapter 9: Reworked final strip command. Relocated paragraphs about directory removal from Chapter 6.   * October 14th, 2003 [greg]: Chapter 8 - Making the LFS system bootable: Expanded Grub details and added a warning.   * October 14th, 2003 [alex]: Appendix A - Updated the contents of Perl and Procps.   * October 14th, 2003 [alex]: Chapter 4 and 5 - Added a suggestion to use $LFS/sources as the working and storage place.   * October 13th, 2003 [greg]: Chapter 9 - Rebooting the system: Reworked umount commands.   * October 11th, 2003 [alex]: Adapted the required disk space values and SBUs, as posted by Bruce Dubbs.   * October 11th, 2003 [alex]: Chapter 5 - Toolchain technical notes: Added and changed some markup.   * October 9th, 2003 [gerard]: Upgraded to lfs-bootscripts-1.12.   * October 9th, 2003 [greg]: Performed internal markup reworking to fix an extraneous whitespace problem in "tidy generated" web site pages. Essentially replace all occurrences of with (and the matching closing tags).   * October 9th, 2003 [alex]: Chapter 6 - Basic Networking: Moved one half to the Lfs-Utils section, the other half to Perl.   * October 8th, 2003 [alex]: Chapter 8 - Making bootable: Adapted the style of the screens, and reworded some paragraphs.   * October 8th, 2003 [alex]: Removed a series of unused entities.   * October 7th, 2003 [jeremy]: Added notes to the linking tests in chapter 5 and 6 stating that blank output is a bad thing.   * October 7th, 2003 [alex]: Changed the patch entities to contain the full filename instead of just the version number.   * October 7th, 2003 [jeremy]: Chapter 1 - Added a note regarding # LFS-support on IRC.   * October 7th, 2003 [greg]: Preface: Add note about the Essential Pre-Reading Hint. Closes Bug 585.   * October 6th, 2003 [alex]: Changed the style of the Contents subsections in Chapters 5 and 6 and Appendix A.   * October 6th, 2003 [greg]: Simplified seds in "Locking in Glibc" and "Re-adjusting the toolchain" sections. Rearranged "How things are going to be done" section.   * October 5th, 2003 [greg]: Chapter 5: Added new section "Toolchain technical notes". Integrated and scaled back the old "Why we use static linking" section. Closes Bug 658.   * October 4th, 2003 [alex]: Minor rewordings and additions of markup here and there.   * October 4th, 2003 [greg]: Chapter 5 - Binutils Pass 1: Added extra LDFLAGS to ensure static rebuild of ld.   * October 2nd, 2003 [greg]: Chapter 6: Reinstated INSTALL=/tools/bin/ install for linker adjustment command due to issues on hosts where a ginstall symlink exists. This renders the "install" symlinks redundant, so removed those too.   * October 2nd, 2003 [greg]: Chapter 6 - Shadow: Enabled MD5 passwords. Closes Bug 600.   * September 27th, 2003 [greg]: Chapter 5 - Expect: Tweaked install so that redundant scripts are not installed. Chapter 6 - Creating essential symlinks: Removed redundant links. Chapter 6 - man: Removed PATH, closes Bug 574.   * September 27th, 2003 [greg]: Added Tcl, Expect and DejaGnu items to Appendix A. Closes Bug 661.   * September 26th, 2003 [jeremy]: Added new workaround for the devpts problems.   * September 24th, 2003 [greg]: Various changes across the board addressing Bug 675.   * September 24th, 2003 [alex]: Appendix A - Changed the style of the short descriptions, and the content of most of them too.   * September 22nd, 2003 [greg]: Chapter 8 - Creating the /etc/fstab file: Made mounting devpts the default.   * September 22nd, 2003 [jeremy]: Added Net-tools patch to fix mii-tool compilation.   * September 22nd, 2003 [jwrober]: Chapter 5 - Updated the Why Static page to more accurately represent the difference between statically and dynamically linked binaries. Thanks to Ian Molton for pointing this out. Fixes Bug 602.   * September 22nd, 2003 [jeremy]: Removed the make command from DejaGnu, since it performs nothing.   * September 22nd, 2003 [jeremy]: Removed the -k from Tcl's make check, since it's not expected to have failures anymore   * September 22nd, 2003 [jeremy]: Changed the reference to the man hint to a pointer to BLFS.   * September 22nd, 2003 [jeremy]: Added a note to remember to mount devpts if you exit and re-enter chroot.   * September 22nd, 2003 [jeremy]: Removed make check from Patch and Diffutils, since these tests perform no actions.   * September 22nd, 2003 [greg]: Chapter 5 - Setting up the environment: Added unset CC CXX CPP LD_LIBRARY_PATH LD_PRELOAD to .bash_profile to stop accidental build breakage.   * September 20th, 2003 [greg]: Chapter 5 - GCC Pass 2: Updated to gcc-3.3.1-specs-2.patch. Ncurses: added --enable-overwrite and description.   * September 19th, 2003 [jeremy]: Corrected bash tags for proper use of the +h flag to bash.   * September 19th, 2003 [jwrober]: Various updates to the acknowledgments page.   * September 18th, 2003 [jeremy]: Chapter 5 - GCC Pass 2: Added some extra comments regarding the 3 tarballs to unpack.   * September 17th, 2003 [greg]: Chapter 6 - GCC-2.95.3: Added rationale notes.   * September 17th, 2003 [jwrober]: Updated the acknowledgments page to match the website.   * September 17th, 2003 [jeremy]: Upgraded File to 4.04.   * September 17th, 2003 [jeremy]: Chapter 6 - Changed 2 of the occurrences of exec bash --login to include the +h directive.   * September 17th, 2003 [greg]: Chapters 5 and 6 - Locking in Glibc and Re-adjusting the toolchain: Do "make -C ld install" instead of "make -C ld install-data-local" to install a whole new linker instead of just the new ldscripts.   * September 17th, 2003 [alex]: Normalized the spelling of 'Tcl' and 'DejaGnu', following their own documentation.   * September 17th, 2003 [alex]: Properly alphabetized the dependencies.   * September 16th, 2003 [alex]: Finally updated the dependencies for the new Coreutils.   * September 16th, 2003 [greg]: Chapters 5 and 6 - Locking in Glibc and Re-adjusting the toolchain: Added sanity checks.   * September 16th, 2003 [greg]: Chapters 5 and 6 - Binutils, GCC, and Glibc: Added notes on the test suites.   * September 15th, 2003 [alex]: Corrected several typos and some inconsistencies.   * September 14th, 2003 [greg]: Chapter 6 - Revised chroot command: Removed no longer needed set +h.   * September 14th, 2003 [alex]: Fixed some typos, and added some markup. Dropped the removal of program files from the Stripping section in Chapter 5.   * September 14th, 2003 [greg]: Chapter 6 - Create essential symlinks: Add symlink /usr/lib/libgcc_s.so.1 to allow GCC abi_check to run. Future NPTL needs this as well.   * September 13th, 2003 [jwrober]: Added PLFS hint text to the page in Chapter 6 for creating passwd and group: bug 596.   * September 13th, 2003 [jwrober]: Updated the "How things are going to be done" page to include more of the PLFS hint's text.   * September 13th, 2003 [jwrober]: Preface - Merged whoread and whonotread into a single audience page.   * September 13th, 2003 [greg]: Chapter 2 - Added new section about the test suites.   * September 12th, 2003 [jeremy]: Chapter 5 - Ncurses: Added description for the --without-ada configure switch.   * September 12th, 2003 [jeremy]: Chapter 5 - Gawk: Added the test suite   * September 12th, 2003 [jeremy]: Chapter 5 - Grep: Added descriptions of configure switches courtesy of Anderson Lizardo   * September 12th, 2003 [gerard]: Removed /usr/lib/locale directory creation - it's created during Chapter 6 - Glibc where it's more relevant.   * September 11th, 2003 [jwrober]: Chapter 5 - Fixed GCC Pass 2 specs patch text to be more vague, but in actuality more accurate - provided by Anderson Lizardo.   * September 11th, 2003 [jwrober]: Chapter 5 - Grammar fix in Tcl install directions provided by Anderson Lizardo.   * September 11th, 2003 [jwrober]: Chapter 5 - Small textual change in the locking in Glibc page for /lib/ld.so.1 provided by Anderson Lizardo.   * September 11th, 2003 [jeremy]: Added bootloader setup to Chapter 8, after the addition of Grub to the book.   * September 11th, 2003 [gerard]: Removed Bin86 and LILO and replaced it with Grub.   * September 11th, 2003 [jeremy]: Dropped non-toolchain tests to optional actions. Added a note to use the Wiki for failed tests.   * September 11th, 2003 [jeremy]: Added Bison patch, backported from CVS, to fix pwlib compilation problems   * September 11th, 2003 [jeremy]: Added Greg's patch to GCC to suppress the installation of libiberty, and changed Binutils to allow its libiberty to stay.   * September 11th, 2003 [jeremy]: Added caution tags around the reminder to not delete the Binutils source and build directories in Chapter 5.   * September 11th, 2003 [jeremy]: Added new perl-libc-3 patch from Anderson Lizardo   * September 9th, 2003 [jwrober]: Fixed the Findutils package download link on the packages page closing bug 578.   * September 9th, 2003 [jeremy]: Chapter 6 - GCC 2.95.3: Removed compilation of C++, added Zack's return-type patch.   * September 9th, 2003 [jeremy]: Chapter 6 - Coreutils: Added coreutils-5.0-hostname-2.patch, which suppresses the build of the hostname binary, and also suppresses its check.   * September 9th, 2003 [jeremy]: Added some notes regarding failed tests to Glibc and DejaGnu.   * September 9th, 2003 [jeremy]: Glibc - Added commands to both Chapter 5 and 6 to include minimum locales necessary for checks.   * September 9th, 2003 [jeremy]: Chapter 6 - Removed Zlib's munging of CFLAGS in favor of a note to add -fPIC.   * September 8th, 2003 [matt]: Chapter 5 - Fixed the rm command that deletes unneeded documentation from /tools/share.   * September 6th, 2003 [matt]: Chapter 6 - Removed a reference to "the static" directory in the intro.   * September 6th, 2003 [jeremy]: Chapter 4 - Updated download locations for some packages.   * September 5th, 2003 [jeremy]: Chapter 5 - GCC Pass 2: Corrected the make check error explanation   * September 5th, 2003 [jeremy]: Chapter 6 - Makedev: Changed the default device creation to generic-nopty, because we now use devpts by default.   * September 5th, 2003 [jeremy]: Chapter 6 - GCC: Corrected wording to reflect the removal of the /usr/lib/cpp symlink.   * September 5th, 2003 [jeremy]: Corrected perl libc patch to -2, changing the old /stage1 structure to /tools   * September 5th, 2003 [matt]: Chapter 6 - Updated GCC specs patch and upgraded to man-1.5m2   * September 4th, 2003 [jeremy]: Chapter 6 - Creating Directories: Eliminated the creation of /usr/tmp - Closes bug 176.   * September 4th, 2003 [jeremy]: Chapter 6 - Mounting Proc: Added mounting the devpts filesystem into chroot here. Closes bug 533.   * September 4th, 2003 [jeremy]: Chapter 6 - Mounting Proc: Added a warning at the end regarding checking that proc is still mounted if you stop and restart the lfs process.   * September 4th, 2003 [jeremy]: Chapter 6 - Gzip: Altered text to better explain the reason behind the sed command used in the gzip installation. Closes bug 551.   * September 4th, 2003 [jeremy]: Chapter 4 - Downloading patches: Added a note regarding Tushar's patches project, and a link to the patches home page.   * September 3rd, 2003 [matt]: Fixed issue with Util-linux not utilizing headers and libraries installed in /stage1.   * September 3rd, 2003 [matt]: Removed "rm /bin/pwd" instruction from Chapter 6 kernel-headers installation as the link is still required by Glibc's installation.   * September 2nd, 2003 [alex]: Adjusted all the SBUs from the values posted by Jeremy.   * September 2nd, 2003 [alex]: Finally got around to renaming /stage1 to / tools.   * September 2nd, 2003 [alex]: Merged several of the main book structure files.   * September 2nd, 2003 [alex]: Alphabetized download lists, added note to Tcl instructions.   * September 2nd, 2003 [alex]: Reworded Organization, $LFS and SBUs sections.   * September 1, 2003 [jeremy] - Chapter 6 - Groff - Added note about choice of A4 or letter for the PAGE variable.   * September 1, 2003 [jeremy] - Added in shadow newgrp patch from Greg Schafer   * August 31, 2003 [jeremy] - Chapter 6 - Inetutils - added the --disable-whois and --disable-servers flags   * August 31, 2003 [jeremy] - Added in Greg's new instructions for GCC 3.3.1 with respect to the fixincludes process. Also added extra verbiage to the Locking in Glibc and GCC Pass 2 pages on the fixincludes process.   * August 31st, 2003 [alex]: Reworded some paragraphs, added missing markup, and rearranged the changelog.   * August 31st, 2003 [alex]: Wrapped the 'Last checked' lines in parentheses. Several other small retouches.   * August 30, 2003 [jeremy] - Updated fix-includes patch to GCC 3.3.1   * August 29, 2003 [jeremy] - Glibc - updated instructions with the sscanf patch from patches.   * August 29, 2003 [jeremy] - Updated GCC to version 3.3.1, including fixes based on Zack's mini-hint for GCC 3.3, and patches from his docs.   * August 29th, 2003 [alex]: Removed obsolete Netkit-base, Fileutils, Sh-utils, and Textutils files.   * August 29th, 2003 [alex]: Added some missing markup, changed a few / static's to /stage1's.   * August 29th, 2003 [alex]: Chapter 06 - Added all the missing text lines before the make checks, and reworded other lines.   * August 28, 2003 [matt] - Updated packages to linux-2.4.22, man-pages-1.60, expect-5.39.0, findutils-4.1.20 and tcl-8.4.4   * August 28, 2003 [jeremy] - New bash-2.05b-2.patch file to include the 7 patches from ftp.gnu.org   * August 28th, 2003 [alex]: Chapter 06 - Re-adjusting toolchain: Added a forgotten backslash.   * August 28th, 2003 [alex]: Fixed a few typos and added some missing markup.   * August 28th, 2003 [alex]: Chapter 06 - Binutils and GCC: Integrated text from the pure-lfs hint.   * August 27, 2003 [jeremy] - Chapter 06 - Inetutils: Added --sysconfdir=/ etc --localstatedir=/var and moved the ping binary from /usr/bin to /bin   * August 27th, 2003 [alex]: Chapter 06 - Glibc: Integrated text from the pure-lfs hint.   * August 26, 2003 [jeremy] - Chapter 07 - Creating /etc/hosts: Changed www.mydomain.org to .mydomain.org   * August 26th, 2003 [alex]: Chapter 06 & 08 - Moved the installation of the kernel manpages from chapter 6 to 8.   * August 26, 2003 [jeremy] - Chapter 04 - Mounting the LFS partition: Added text regarding mounting with too restrictive permissions.   * August 26, 2003 [jeremy] - Chapter 06 - Creating Directories: Added the creation of the /dev/shm directory.   * August 26, 2003 [jeremy] - Chapter 08 - Creating fstab: Added the mount of tmpfs filesystem to /dev/shm.   * August 26, 2003 [jeremy] - Chapter 08 - Kernel Installation: Added a reminder to compile tmpfs support into the kernel.   * August 25th, 2003 [alex]: Chapter 06 - Rewrote the installation text of Shadow and Util-Linux while correcting some typos.   * August 25th, 2003 [alex]: Chapter 05 & 06 - Made the "Locking in" and "Re-adjusting" look similar.   * August 24th, 2003 [alex]: Chapter 04 - Merged the many little files into one file. Gave packages and patches a separate page.   * August 17th, 2003 [alex]: Chapter 05 - From Bash to Perl: put text in between commands. Added a section on stripping unneeded symbols to decrease the size of the tools.   * August 16th, 2003 [alex]: Chapter 05 - From Make to Texinfo: put text in between commands.   * August 11th, 2003 [alex]: Chapter 05 - From Binutils Pass 1 to Findutils: several small textual adjustments. For the second passes not giving the contents and dependencies.   * August 11th, 2003 [alex]: Chapter 04 - Listed separate core, g++, and test suite tarballs for GCC.   * August 11th, 2003 [alex]: Chapter 04 - Suppressed the mention of a wget script.   * August 9th, 2003 [alex]: Chapter 05 - Binutils Pass 2 and GCC Pass 2: integrated some text from the pure-lfs hint.   * August 8th, 2003 [alex]: Chapter 05 - Tcl, Expect, and DejaGnu: added some text.   * August 6th, 2003 [gerard]: Applied Alex Groenewoud's patch that adds Appendix B, providing a list of all installed programs and libraries plus references to the installation pages.   * July 30th, 2003 [gerard]: Chapter 06 - Vim: Changed the way the global vimrc and gvimrc locations are defined.   * July 30th, 2003 [gerard]: Chapter 05 - Binutils Pass 2: removed the lib patch, it's no longer needed with the binutils-2.14 upgrade.   * July 30th, 2003 [gerard]: Chapter 05 Binutils Pass 1: Added make configure-host.   * July 30th, 2003 [gerard]: Upgraded to binutils-2.14, linux-2.4.21, expect-5.38.4, gawk-3.1.3, texinfo-4.6, util-linux-2.12, man-pages-1.58, lfs-utils-0.3, vim-6.2, gettext-0.12.1, automake-1.7.6, file-4.03, e2fsprogs-1.34, procps-3.1.11, psmisc-21.3   * June 3rd, 2003 [gerard]: Chapter 06 - Gawk: removed the removal of /bin/ awk. This symlink isn't created anymore.   * May 21st, 2003 [gerard]: Chapter 06 - GCC-2.95.3: Added /opt/gcc-2.95.3/ lib to the /etc/ld.so.conf file so the libraries can be found during run-time.   * May 21st, 2003 [gerard]: Chapter 05 - Gzip: Simplified commands.   * May 21st, 2003 [gerard]: Chapter 05 - Bzip2: Simplified commands.   * May 21st, 2003 [gerard]: Chapter 06 - Shadow: Added the grpconv command to complement the enabling of all shadowed passwords.   * May 21st, 2003 [winkie]: Chapter 06 - Creating Files: All those ln commands can be made into a few long ln commands.   * May 21st, 2003 [winkie]: Chapter 05 - Installing Glibc: Create an ld.so.conf file before building Glibc, to prevent an (harmless) error.   * May 21st, 2003 [winkie]: Chapter 06 - Installing Glibc: Don't bother doing the 'exec /stage1/bin/bash' stuff, it doesn't do anything now that we use PLFS.   * May 21st, 2003 [winkie]: Chapter 05 & 06 - Installing Coreutils: Only test the non-root stuff in Chapter 05, but test everything in Chapter 06.   * May 21st, 2003 [winkie]: Chapter 05 - Installing Expect: Don't bother passing anything more than --prefix=/stage1. None of it is needed.   * May 16th, 2003 [gerard]: Chapter 06: Net-tools: Changed make install to make update.   * May 15th, 2003 [timothy]: Chapter 05: Installing Patch: Added CPPFLAGS= -D_GNU_SOURCE before ./configure to fix patch build on PPC.   * May 13th, 2003 [gerard]: Chapter 06: When we exec /path/to/bash --login, also run set +h to keep the hashing option turned off. Fixes bug #531   * May 13th, 2003 [gerard]: Chapter 06 - Basic Network: Changed the single quotes to double quotes in the echo command. Without it, $(hostname) won't expand which defeats the sole purpose of this command - to make Perl's hostname check work.   * May 13th, 2003 [winkie]: Removed all occurrences &&. Updated bug syntax. Added "make check/test" where necessary in Chapter 6.   * May 13th, 2003 [winkie]: Chapter 06: Applied "Changing ownership" patch to polish the text. Closes bug #511.   * May 13th, 2003 [winkie]: Chapter 06: Applied "Configuring system components" patch to polish the text. Closes bug #510.   * May 13th, 2003 [gerard]: Chapter 06: Removed Tcl, Expect and DejaGnu. Nothing uses this once past GCC in chapter 6. The versions in /stage1/bin do the job just fine.   * May 13th, 2003 [winkie]: Chapter 06 - Installing Shadow: Touching the / usr/bin/passwd file before installation. Not doing so results in Shadow thinking passwd will be in /bin/passwd.   * May 13th, 2003 [winkie]: Chapter 06 - Installing Procps: Remove the /lib/ libproc.so symlink. No package outside of Procps itself uses this library, and none should.   * May 13th, 2003 [winkie]: Chapter 06 - Installing Net-tools: Run "make config" before doing make. Fixes bugs #462 and #497.   * May 13th, 2003 [gerard]: Chapter 06 - Ncurses: Added the vsscanf patch.   * May 12th, 2003 [gerard]: Chapter 05 - Gzip: Removed make check. It doesn't do anything.   * May 12th, 2003 [winkie]: Chapter 05 - Installing Texinfo: Don't install the texmf data. It's not used by anything.   * May 12th, 2003 [winkie]: Chapter 05 & 06 - Installing Ncurses: In Chapter 6, symlink creation has been updated to include libcurses.*, and libncurses++.a has its properties changed to 644. Chapter 5 doesn't need any libcurses.* so those are removed.   * May 12th, 2003 [gerard]: Chapter 06 - Basic Network: Added $(hostname) to /etc/hosts, without it Perl's hostname test doesn't pass.   * May 12th, 2003 [gerard]: Chapter 06 - Installing GCC: Don't try to remove /usr/include/libiberty.h. It isn't installed in the first place.   * May 12th, 2003 [winkie]: Upgraded to findutils-4.1.7, gzip-1.3.5, and tar-1.13.25.   * May 12th, 2003 [winkie]: Chapter 05 - Installing Perl: Added extra commands to build certain modules into Perl. This is to accommodate the Coreutils "make check". Partially fixes bug #528.   * May 12th, 2003 [winkie]: Chapter 05 - Installing Gzip: Nothing in Chapter 6 checks for or uses the uncompress command, therefore we shouldn't create it.   * May 12th, 2003 [winkie]: Chapter 05 - Installing Bzip2: Running "make" implies "make check", therefore there is no reason whatsoever for us to run it manually.   * May 12th, 2003 [winkie]: Chapter 05 - Installing Lfs-Utils: Removed. The only package that checks for mktemp before it is installed is GCC, and that's only for gccbug.   * May 11th, 2003 [gerard]: Chapter 06 - GCC-2.95.3: Added --enable-threads= posix as well to complete the C++ addition.   * May 11th, 2003 [gerard]: Chapter 06 - GCC-2.95.3: Added --enable-languages=c,c++ to fix that GCC's version bug with regards to -Wreturn-type. Fixes bug #525   * May 11th, 2003 [gerard]: Chapter 05 - Bash: Removed the --without-bash-malloc configure option.   * May 11th, 2003 [gerard]: Updated to gcc-3.2.3-specs-4.patch.   * May 11th, 2003 [winkie]: Chapter 06 - Setting up Basic Networking: Added section. Create a basic /etc/hosts files, and create /etc/services and / etc/protocols from IANA. Fixes bugs #359 & #515.   * May 11th, 2003 [winkie]: Upgrading to lfs-utils-0.2.2. This adds two files needed for proper networking configuration.   * May 11th, 2003 [winkie]: Removed Netkit-base 0.17. Added Inetutils 1.4.2. Fixes bug #490.   * May 11th, 2003 [winkie]: Added lfs-utils-0.2.1. Fixes bug #493.   * May 11th, 2003 [winkie]: Chapter 06 - Installing Ncurses: Fix up the symlinks so that they follow suit of other library symlinks. No more weirdness here.   * May 11th, 2003 [winkie]: Chapter 06 - Installing Procps: Removed XSCPT="" cruft and its corresponding paragraph. This stuff isn't needed anymore.   * May 11th, 2003 [winkie]: Chapter 06 - Installing Ncurses: Pass --without-debug to the configure script. It seems to have gotten lost at some point.   * May 11th, 2003 [timothy]: Chapter 5 & 6 - Installing Bzip2, Installing Zlib: Modified build commands per bug #524.   * May 11th, 2003 [winkie]: Chapter 06 - Installing Glibc: Install the linuxthreads man pages, too. This got lost somewhere.   * May 11th, 2003 [winkie]: Chapter 06 - Installing Grep: Added --with-included-regex to prevent Grep from using Glibc's somewhat bugged regex.   * May 11th, 2003 [winkie]: Chapter 06 - Installing Coreutils: Fix some functionality of the uname command with a patch.   * May 11th, 2003 [winkie]: Chapter 06 - Installing Net-tools: Just do regular old "make install" instead of "make update". The latter works fine now.   * May 11th, 2003 [winkie]: Chapter 06 - Installing GCC: After installation, remove /usr/include/libiberty.h. It is not used outside of the GCC build tree.   * May 11th, 2003 [winkie]: Upgraded to Bash 2.05b and added its patch.   * May 11th, 2003 [winkie]: Chapter 06 - Installing Zlib: Apply a patch to fix the buffer overflow in gzprintf().   * May 11th, 2003 [winkie]: Chapter 06 - Configuring system components: Moved the creation of the btmp, wtmp, lastlog and utmp to just before Shadow, so that they are detected at their proper locations.   * May 10th, 2003 [winkie]: Chapter 06 - Installing Automake: Run "make" before installing. This is needed now with the newer releases of Automake.   * May 10th, 2003 [winkie]: Chapter 06 - Installing Vim: Removed the patch. It hasn't been required since GCC 3.2.1.   * May 10th, 2003 [winkie]: Chapter 06 - Creating the mtab file: Removed. Mounting /proc has the side effect of creating /etc/mtab for us.   * May 10th, 2003 [winkie]: Chapter 06 - Installing Make: Removed modification of /usr/bin/make file. It is no longer mistakenly installed with strange ownership or permissions.   * May 10th, 2003 [winkie]: Chapter 06 - Installing Glibc: Made /etc/ localtime a file instead of a symlink. The symlink method breaks on systems where /usr is a separate partition.   * May 10th, 2003 [winkie]: Chapter 06 - Installing E2fsprogs: Removed install-info commands for e2fsprogs. The "make install" target handles this for us.   * May 10th, 2003 [gerard]: Removed all CFLAGS and LDFLAGS variables where they are not essential (so, not including static binutils, GCC and compiling Zlib with -fPIC).   * May 10th, 2003 [gerard]: Chapter 05 - Binutils (pass1, pass2), locking in Glibc and adjusting toolchain: Changed tooldir to /stage1 (likewise we use tooldir=/usr in Chapter 6).   * May 10th, 2003 [gerard]: Chapter 05 - Kernel headers: Removed the usage of cp -H because there are distributions out there that do not know about the -H option.   * May 10th, 2003 [gerard]: New gcc-3.2.3-specs-3.patch.   * May 10th, 2003 [gerard]: Chapter 06 - Adjusting toolchain: Made it more architecture-independent.   * May 10th, 2003 [gerard]: Chapter 05 - Locking in Glibc: Made it more architecture-independent.   * May 7th, 2003 [gerard]: Removed GCC No Debug patches. No longer assume gcc-core and gcc-g++ packages are downloaded, so added appropriate --enable-languages options.   * May 7th, 2003 [gerard]: Removed Chapter 6 - Glibc-Pass2. It's not needed anymore with the pure-lfs integration.   * May 7th, 2003 [gerard]: Downgraded to flex-2.5.4a again. Newer versions just don't work properly.   * May 5th, 2003 [gerard]: Removed zlib installation from chapter 5 (its inclusion was a mistake).   * May 5th, 2003 [gerard]: Various bug fixes that were introduced during the pure-lfs integration.   * May 2nd, 2003 [gerard]: Upgraded to: automake-1.7.4, e2fsprogs-1.33, file-4.02, flex-2.5.31, gawk-3.1.2, gcc-3.2.3, glibc-2.3.2, grep-2.5.1, groff-1.19, less-381, libtool-1.5, man-1.5l, man-pages-1.56, modutils-2.4.25, procps-3.1.8, sed-4.0.7, sysvinit-2.85, texinfo-4.5, util-linux-2.11z   * May 2nd, 2003 [gerard]: Removed fileutils-4.1, sh-utils-2.0, textutils-2.1 (all replaced with coreutils-5.0).   * May 2nd, 2003 [gerard]: Added binutils-2.13.2-libc.patch, coreutils-5.0, dejagnu-1.4.3, expect-5.38, gawk-3.1.2, gcc-2.95.3, tcl-8.4.2   * May 2nd, 2003 [gerard] - Integrated new installation method from the Pure LFS hint written by Greg Schafer and Ryan Oliver. Release of version 4.1 on April 28th, 2003. ----------------------------------------------------------------------------- 1.5. Resources ----------------------------------------------------------------------------- 1.5.1. FAQ If during the building of your LFS system you encounter any errors, or have any questions, or think you found a typo in the book, then please first consult the FAQ (Frequently Asked Questions) at [http:// www.linuxfromscratch.org/faq/] http://www.linuxfromscratch.org/faq/. ----------------------------------------------------------------------------- 1.5.2. IRC Several members of the LFS community offer assistance on our community IRC server. Before you utilize this mode of support, we ask that you've at least checked the LFS FAQ and the mailing list archives for the answer to your question. You can find the IRC server at irc.linuxfromscratch.org port 6667. The support channel is named #LFS-support. ----------------------------------------------------------------------------- 1.5.3. Mailing lists The linuxfromscratch.org server is hosting a number of mailing lists used for the development of the LFS project. These lists include, among others, the main development and support lists. For information on which lists are available, how to subscribe to them, their archive locations, and so on, visit [http://www.linuxfromscratch.org/ mail.html] http://www.linuxfromscratch.org/mail.html. ----------------------------------------------------------------------------- 1.5.4. News server All the mailing lists hosted at linuxfromscratch.org are also accessible via the NNTP server. All messages posted to a mailing list will be copied to the correspondent newsgroup, and vice versa. The news server can be reached at news.linuxfromscratch.org. ----------------------------------------------------------------------------- 1.5.5. Mirror sites The LFS project has a number of mirrors set up world-wide to make accessing the website and downloading the required packages more convenient. Please visit the website at [http://www.linuxfromscratch.org/] http:// www.linuxfromscratch.org/ for a list of current mirrors. ----------------------------------------------------------------------------- 1.5.6. Contact information Please direct your all your questions and comments to one of the LFS mailing lists (see above). But if you need to reach Gerard Beekmans personally, send an email to [mailto:gerard@linuxfromscratch.org] gerard@linuxfromscratch.org. ----------------------------------------------------------------------------- 1.6. Acknowledgments We would like to thank the following people and organizations for their contributions to the Linux From Scratch Project. ----------------------------------------------------------------------------- 1.6.1. Current Project Team Members   * Gerard Beekmans -- Linux-From-Scratch initiator, LFS Project organizer.   * Matthew Burgess -- LFS General Package maintainer, LFS Book editor.   * Craig Colton -- LFS, ALFS, BLFS and Hints Project logo creator.   * Jeroen Coumans -- Website developer, FAQ maintainer.   * Bruce Dubbs -- LFS Quality Assurance Team leader, BLFS Book editor.   * Alex Groenewoud -- LFS Book editor.   * Mark Hymers -- CVS maintainer, BLFS Book creator, former LFS Book editor.   * James Iwanek -- System Administration Team member.   * Nicholas Leippe -- Wiki maintainer.   * Anderson Lizardo -- Website backend scripts creator and maintainer.   * Bill Maltby -- LFS Project organizer.   * Scot Mc Pherson -- LFS NNTP gateway maintainer.   * Ryan Oliver -- Testing Team leader, co-creator of PLFS.   * James Robertson -- Bugzilla maintainer, Wiki developer, LFS Book editor.   * Greg Schafer -- Toolchain maintainer, LFS Book editor, co-creator of PLFS.   * Tushar Teredesai -- BLFS Book editor, Hints and Patches Projects maintainer.   * Jeremy Utley -- LFS Book editor, Bugzilla maintainer.   * Countless other people on the various LFS and BLFS mailing lists who are making this book happen by giving their suggestions, testing the book and submitting bug reports, instructions and their experiences with installing various packages. ----------------------------------------------------------------------------- 1.6.2. Translators   * Manuel Canales Esparcia -- Spanish LFS translation project.   * Johan Lenglet -- French LFS translation project.   * Anderson Lizardo -- Portuguese LFS translation project. ----------------------------------------------------------------------------- 1.6.3. Mirror Maintainers   * [mailto:jason@dstc.edu.au] Jason Andrade -- au.linuxfromscratch.org mirror.   * [mailto:lost@l-w.net] William Astle -- ca.linuxfromscratch.org mirror.   * [mailto:baque@cict.fr] Baque -- lfs.cict.fr mirror.   * [mailto:stevie@stevie20.de] Stephan Brendel -- lfs.netservice-neuss.de mirror.   * [mailto:ian@ichilton.co.uk] Ian Chilton -- us.linuxfromscratch.org, linuxfromscratch.co.uk mirrors.   * Fredrik Danerklint -- se.linuxfromscratch.org mirror.   * David D.W. Downey -- lfs.learnbyexample.com mirror.   * Eduardo B. Fonseca -- br.linuxfromscratch.org mirror.   * [mailto:hrx@hrxnet.de] Hagen Herrschaft -- de.linuxfromscratch.org mirror.   * [mailto:tim@idge.net] Tim Jackson -- linuxfromscratch.idge.net mirror.   * [mailto:barna@siker.hu] Barna Koczka -- hu.linuxfromscratch.org mirror.   * Roel Neefs -- linuxfromscratch.rave.org mirror.   * [mailto:sime@dot-sime.com] Simon Nicoll -- uk.linuxfromscratch.org mirror.   * Ervin S. Odisho -- lfs.activalink.net mirror.   * [mailto:guido@primerelay.net] Guido Passet -- nl.linuxfromscratch.org mirror.   * [mailto:miha@xuy.biz] Mikhail Pastukhov -- lfs.130th.net mirror.   * [mailto:jpolen@rackspace.com] Jeremy Polen -- us2.linuxfromscratch.org mirror.   * [http://www.mirror.ac.uk] UK Mirror Service -- linuxfromscratch.mirror.co.uk mirror.   * [mailto:thomas@sofagang.dk] Thomas Skyt -- dk.linuxfromscratch.org mirror.   * Antonin Sprinzl -- at.linuxfromscratch.org mirror.   * [mailto:dag@stenstad.net] Dag Stenstad for providing no.linuxfromscratch.org and [mailto:ian@ichilton.co.uk] Ian Chilton for running it.   * Parisian sysadmins -- www2.fr.linuxfromscratch.org mirror.   * Jesse Tie-Ten-Quee for providing and running the linuxfromscratch.org server.   * [mailto:velin@zadnik.org] Alexander Velin -- bg.linuxfromscratch.org mirror.   * [mailto:Martin.Voss@ada.de] Martin Voss -- lfs.linux-matrix.net mirror.   * [mailto:pyng@spam.averse.net] Pui Yong -- sg.linuxfromscratch.org mirror. ----------------------------------------------------------------------------- 1.6.4. Donators   * [mailto:dean@vipersoft.co.uk] Dean Benson for several monetary contributions.   * [http://www.dreamwvr.com] DREAMWVR.COM for their past sponsorship of donating various resources to the LFS and related sub projects.   * [mailto:hrx@hrxnet.de] Hagen Herrschaft for donating a 2.2 GHz P4 system, now running under the name of lorien.   * [http://www.oreilly.com] O'Reilly for donating books on SQL and PHP.   * [http://www.vasoftware.com] VA Software who, on behalf of [http:// www.linux.com] Linux.com, donated a VA Linux 420 (former StartX SP2) workstation.   * [mailto:strider@linux.com] Mark Stone for donating shadowfax, the first linuxfromscratch.org server, a 750 MHz P3 with 512 MB RAM and two 9 GB SCSI drives. When the server moved it was renamed to belgarath.   * Jesse Tie-Ten-Quee for donating a Yamaha CDRW 8824E CD-writer.   * Countless other people on the various LFS mailing lists who are making this book better by giving their suggestions, submitting bug reports, and throwing in their criticism. ----------------------------------------------------------------------------- 1.6.5. Former Team Members and Contributors   * Timothy Bauscher -- LFS Book editor, Hints Project maintainer.   * Robert Briggs for originally donating the linuxfromscratch.org and linuxfromscratch.com domain names.   * [mailto:ian@ichilton.co.uk] Ian Chilton for maintaining the Hints project.   * Marc Heerdink -- LFS Book editor.   * Seth W. Klein -- LFS FAQ creator.   * Garrett LeSage -- Original LFS banner creator.   * Simon Perreault -- Hints Project maintainer.   * [mailto:Geert.Poels@skynet.be] Geert Poels -- Original BLFS banner creator; based on the LFS banner by Garrett LeSage.   * [mailto:bkenoah@oswd.org] Frank Skettino for the initial design of the old website -- have a look at [http://www.oswd.org /] http://www.oswd.org/.   * Jesse Tie-Ten-Quee for answering countless questions on IRC and having a great deal of patience. ----------------------------------------------------------------------------- Chapter 2. Important information ----------------------------------------------------------------------------- 2.1. About $LFS Please read the following paragraphs carefully. Throughout this book the variable LFS will be used frequently. $LFS must at all times be replaced with the directory where the partition that contains the LFS system is mounted. How to create and where to mount the partition will be explained in full detail in Chapter 3. For the moment let's assume that the LFS partition is mounted on /mnt/lfs. When you are told to run a command like ./configure --prefix=$LFS/tools, you actually have to execute ./configure --prefix=/mnt/lfs/tools. It's important that this is done no matter where it is read; be it in commands entered in a shell, or in a file edited or created. A possible solution is to set the environment variable LFS. This way $LFS can be entered literally instead of replacing it with /mnt/lfs. This is accomplished by running: export LFS=/mnt/lfs Now, if you are told to run a command such as ./configure --prefix=$LFS/tools , then you may type it literally. Your shell will replace "$LFS" with "/mnt/ lfs" when it processes the command line (that is, when you hit Enter after having typed the command). ----------------------------------------------------------------------------- 2.2. About SBUs 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 Static Binutils Unit (abbreviated to SBU). It works like this: the first package you compile in this book is the statically linked Binutils in Chapter 5, 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. For example, the time it takes to build the static version of GCC is 4.4 SBUs. 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. 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-3.3.1 which is known to be approximately 30% slower. 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. ----------------------------------------------------------------------------- 2.3. About the test suites 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 mostly as the developer intended. It does not, however, guarantee that the package is totally bug free. Some test suites are more important than others. For example, the test suites for the core toolchain packages -- GCC, Binutils, and Glibc (the C library) -- 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 period of time to complete, especially on slower hardware. As you progress through the book and encounter the build commands to run the various test suites, we'll guide you on the relative importance of the test suite in question so that you can decide for yourself whether to run it or not. Note A common problem when running the test suites for Binutils and GCC is running out of pseudo terminals (PTYs for short). The symptom is an unusually high number of failing tests. This can happen for any number of reasons. Most likely is that the host system doesn't have the devpts file system set up correctly. We'll discuss this in more detail later on in Chapter 5. ----------------------------------------------------------------------------- 2.4. How to ask for help If you encounter a problem while using this book, and your problem is not listed in the FAQ ([http://www.linuxfromscratch.org/faq] http:// www.linuxfromscratch.org/faq), you will find that most of the people on Internet Relay Chat (IRC) and on the mailing lists are willing to help you. An overview of the LFS mailing lists can be found in Chapter 1 - Mailing lists. To assist us in diagnosing and solving your problem, include as much relevant information as possible in your request for help. ----------------------------------------------------------------------------- 2.4.1. Things to mention Apart from a brief explanation of the problem you're having, the essential things to include in your request are:   * the version of the book you are using (being 5.0),   * the host distribution and version you are using to create LFS from,   * the package or section giving you problems,   * the exact error message or symptom you are receiving,   * whether you have deviated from the book at all. (Note that saying that you've deviated from the book doesn't mean that we won't help you. After all, LFS is about choice. It'll just help us to see other possible causes of your problem.) ----------------------------------------------------------------------------- 2.4.2. Configure problems When something goes wrong during the stage where the configure script is run, look through the config.log file. This file may contain errors encountered during configure which weren't printed to the screen. Include those relevant lines if you decide to ask for help. ----------------------------------------------------------------------------- 2.4.3. Compile problems To help us find the cause of the problem, both screen output and the contents of various files are useful. The screen output from both the ./configure script and the make run can be useful. Don't blindly include the whole thing but on the other hand, don't include too little. As an example, here is some screen output from make: gcc -DALIASPATH=\"/mnt/lfs/usr/share/locale:.\" -DLOCALEDIR=\"/mnt/lfs/usr/share/locale\" -DLIBDIR=\"/mnt/lfs/usr/lib\" -DINCLUDEDIR=\"/mnt/lfs/usr/include\" -DHAVE_CONFIG_H -I. -I. -g -O2 -c getopt1.c gcc -g -O2 -static -o make ar.o arscan.o commands.o dir.o expand.o file.o function.o getopt.o implicit.o job.o main.o misc.o read.o remake.o rule.o signame.o variable.o vpath.o default.o remote-stub.o version.o opt1.o -lutil job.o: In function `load_too_high': /lfs/tmp/make-3.79.1/job.c:1565: undefined reference to `getloadavg' collect2: ld returned 1 exit status make[2]: *** [make] Error 1 make[2]: Leaving directory `/lfs/tmp/make-3.79.1' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/lfs/tmp/make-3.79.1' make: *** [all-recursive-am] Error 2 In this case, many people just include the bottom section where it says: make [2]: *** [make] Error 1 and onwards. This isn't enough for us to diagnose the problem because it only tells us that something went wrong, not what went wrong. The whole section, as in the example above, is what should be included to be helpful, because it includes the command that was executed and the command's error message(s). An excellent article on asking for help on the Internet in general has been written by Eric S. Raymond. It is available online at [http://catb.org/~esr/ faqs/smart-questions.html] http://catb.org/~esr/faqs/smart-questions.html. Read and follow the hints in that document and you are much more likely to get a response to start with and also to get the help you actually need. ----------------------------------------------------------------------------- 2.4.4. Test suite problems Many packages provide a test suite which, depending on the importance of the package, we may encourage you to run. Sometimes packages will generate false or expected failures. If you encounter these, you can check the LFS Wiki page at [http://wiki.linuxfromscratch.org/] http://wiki.linuxfromscratch.org/ to see whether we have already investigated and noted them. If we already know about them, then usually there is no need to be concerned. II. Part II - Preparing for the build Table of Contents 3. Preparing a new partition 3.1. Introduction 3.2. Creating a new partition 3.3. Creating a file system on the new partition 3.4. Mounting the new partition 4. The materials: packages and patches 4.1. Introduction 4.2. All the packages 4.3. Needed patches 5. Constructing a temporary system 5.1. Introduction 5.2. Toolchain technical notes 5.3. Creating the $LFS/tools directory 5.4. Adding the user lfs 5.5. Setting up the environment 5.6. Installing Binutils-2.14 - Pass 1 5.7. Installing GCC-3.3.1 - Pass 1 5.8. Installing Linux-2.4.22 headers 5.9. Installing Glibc-2.3.2 5.10. "Locking in" Glibc 5.11. Installing Tcl-8.4.4 5.12. Installing Expect-5.39.0 5.13. Installing DejaGnu-1.4.3 5.14. Installing GCC-3.3.1 - Pass 2 5.15. Installing Binutils-2.14 - Pass 2 5.16. Installing Gawk-3.1.3 5.17. Installing Coreutils-5.0 5.18. Installing Bzip2-1.0.2 5.19. Installing Gzip-1.3.5 5.20. Installing Diffutils-2.8.1 5.21. Installing Findutils-4.1.20 5.22. Installing Make-3.80 5.23. Installing Grep-2.5.1 5.24. Installing Sed-4.0.7 5.25. Installing Gettext-0.12.1 5.26. Installing Ncurses-5.3 5.27. Installing Patch-2.5.4 5.28. Installing Tar-1.13.25 5.29. Installing Texinfo-4.6 5.30. Installing Bash-2.05b 5.31. Installing Util-linux-2.12 5.32. Installing Perl-5.8.0 5.33. Stripping ----------------------------------------------------------------------------- Chapter 3. Preparing a new partition ----------------------------------------------------------------------------- 3.1. Introduction In this chapter the partition which will host the LFS system is prepared. We will create the partition itself, make a file system on it, and mount it. ----------------------------------------------------------------------------- 3.2. Creating a new partition In order to build our new Linux system, we will need some space: an empty disk partition. If you don't have a free partition, and no room on any of your hard disks to make one, then you could build LFS on the same partition as the one on which your current distribution is installed. This procedure is not recommended for your first LFS install, but if you are short on disk space, and you feel brave, take a look at the hint at [http:// www.linuxfromscratch.org/hints/downloads/files/ lfs_next_to_existing_systems.txt] http://www.linuxfromscratch.org/hints/ downloads/files/lfs_next_to_existing_systems.txt. For a minimal system you will need a partition of around 1.2 GB. This is enough to store all the source tarballs and compile all the packages. But if you intend to use the LFS system as your primary Linux system, you will probably want to install additional software, and will need more space than this, probably around 2 or 3 GB. As we almost never have enough RAM in our box, it is a good idea to use a small disk partition as swap space -- this space is used by the kernel to store seldom-used data to make room in memory for more urgent stuff. The swap partition for your LFS system can be the same one as for your host system, so you won't have to create another if your host system already uses a swap partition. Start a disk partitioning program such as cfdisk or fdisk with an argument naming the hard disk upon which the new partition must be created -- for example /dev/hda for the primary IDE disk. Create a Linux native partition and a swap partition, if needed. Please refer to the man pages of cfdisk or fdisk if you don't yet know how to use the programs. Remember the designation of your new partition -- something like hda5. This book will refer to it as the LFS partition. If you (now) also have a swap partition, remember its designation too. These names will later be needed for the /etc/fstab file. ----------------------------------------------------------------------------- 3.3. Creating a file system on the new partition Now that we have a blank partition, we can create a file system on it. Most widely used in the Linux world is the second extended file system (ext2), but with the high-capacity hard disks of today the so-called journaling file systems are becoming increasingly popular. Here we will create an ext2 file system, but build instructions for other file systems can be found at [http:/ /www.linuxfromscratch.org/blfs/view/stable/postlfs/filesystems.html] http:// www.linuxfromscratch.org/blfs/view/stable/postlfs/filesystems.html. To create an ext2 file system on the LFS partition run the following: mke2fs /dev/xxx Replace xxx with the name of the LFS partition (something like hda5). If you created a (new) swap partition you need to initialize it as a swap partition too (also known as formatting, like you did above with mke2fs) by running: mkswap /dev/yyy Replace yyy with the name of the swap partition. ----------------------------------------------------------------------------- 3.4. Mounting the new partition Now that we've created a file system, we want to be able to access the partition. For that, we need to mount it, and have to choose a mount point. In this book we assume that the file system is mounted under /mnt/lfs, but it doesn't matter what directory you choose. Choose a mount point and assign it to the LFS environment variable by running: export LFS=/mnt/lfs Now create the mount point and mount the LFS file system by running: mkdir -p $LFS mount /dev/xxx $LFS Replace xxx with the designation of the LFS partition. If you have decided to use multiple partitions for LFS (say one for / and another for /usr), mount them like this: mkdir -p $LFS mount /dev/xxx $LFS mkdir $LFS/usr mount /dev/yyy $LFS/usr Of course, replace xxx and yyy with the appropriate partition names. You should also ensure that this new partition is not mounted with permissions that are too restrictive (such as the nosuid, nodev or noatime options). You can run the mount command without any parameters to see with what options the LFS partition is mounted. If you see nosuid, nodev or noatime, you will need to remount it. Now that we've made ourselves a place to work in, we're ready to download the packages. ----------------------------------------------------------------------------- Chapter 4. The materials: packages and patches ----------------------------------------------------------------------------- 4.1. Introduction 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 known 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. All the URLs, when possible, refer to the project's page at [http:// www.freshmeat.net/] 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. 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 [http://linuxfromscratch.org/lfs/print /] http://linuxfromscratch.org/lfs/print/ or, better yet, try one of the alternative means of downloading listed on [http://linuxfromscratch.org/lfs/ packages.html] http://linuxfromscratch.org/lfs/packages.html. 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 $LFS/sources as the place to store the tarballs and patches, and 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. So you may want to execute, as root, the following command before starting your download session: mkdir $LFS/sources And make this directory writable (and sticky) for your normal user -- as you won't do the downloading as root, we guess: chmod a+wt $LFS/sources ----------------------------------------------------------------------------- 4.2. All the packages Download or otherwise obtain the following packages: Autoconf (2.57) - 792 KB: [http://freshmeat.net/projects/autoconf/] http://freshmeat.net/projects/ autoconf/ Automake (1.7.6) - 545 KB: [http://freshmeat.net/projects/automake/] http://freshmeat.net/projects/ automake/ Bash (2.05b) - 1,910 KB: [http://freshmeat.net/projects/gnubash/] http://freshmeat.net/projects/ gnubash/ Binutils (2.14) - 10,666 KB: [http://freshmeat.net/projects/binutils/] http://freshmeat.net/projects/ binutils/ Bison (1.875) - 796 KB: [http://freshmeat.net/projects/bison/] http://freshmeat.net/projects/bison/ Bzip2 (1.0.2) - 650 KB: [http://freshmeat.net/projects/bzip2/] http://freshmeat.net/projects/bzip2/ Coreutils (5.0) - 3,860 KB: [http://freshmeat.net/projects/coreutils/] http://freshmeat.net/projects/ coreutils/ DejaGnu (1.4.3) - 1,775 KB: [http://freshmeat.net/projects/dejagnu/] http://freshmeat.net/projects/ dejagnu/ Diffutils (2.8.1) - 762 KB: [http://freshmeat.net/projects/diffutils/] http://freshmeat.net/projects/ diffutils/ E2fsprogs (1.34) - 3,003 KB: [http://freshmeat.net/projects/e2fsprogs/] http://freshmeat.net/projects/ e2fsprogs/ Ed (0.2) - 182 KB: [http://freshmeat.net/projects/ed/] http://freshmeat.net/projects/ed/ Expect (5.39.0) - 508 KB: [http://freshmeat.net/projects/expect/] http://freshmeat.net/projects/expect/ File (4.04) - 338 KB: (*) See Note Below [http://freshmeat.net/projects/file/] http://freshmeat.net/projects/file/ Findutils (4.1.20) - 760 KB: [http://freshmeat.net/projects/findutils/] http://freshmeat.net/projects/ findutils/ Flex (2.5.4a) - 372 KB: [ftp://ftp.gnu.org/gnu/non-gnu/flex/] ftp://ftp.gnu.org/gnu/non-gnu/flex/ Gawk (3.1.3) - 1,596 KB: [http://freshmeat.net/projects/gnuawk/] http://freshmeat.net/projects/gnuawk/ GCC (2.95.3) - 9,618 KB: [http://freshmeat.net/projects/gcc/] http://freshmeat.net/projects/gcc/ GCC-core (3.3.1) - 10,969 KB: [http://freshmeat.net/projects/gcc/] http://freshmeat.net/projects/gcc/ GCC-g++ (3.3.1) - 2,017 KB: [http://freshmeat.net/projects/gcc/] http://freshmeat.net/projects/gcc/ GCC-testsuite (3.3.1) - 1,033 KB: [http://freshmeat.net/projects/gcc/] http://freshmeat.net/projects/gcc/ Gettext (0.12.1) - 5,593 KB: [http://freshmeat.net/projects/gettext/] http://freshmeat.net/projects/ gettext/ Glibc (2.3.2) - 13,064 KB: [http://freshmeat.net/projects/glibc/] http://freshmeat.net/projects/glibc/ Glibc-linuxthreads (2.3.2) - 211 KB: [http://freshmeat.net/projects/glibc/] http://freshmeat.net/projects/glibc/ Grep (2.5.1) - 545 KB: [http://freshmeat.net/projects/grep/] http://freshmeat.net/projects/grep/ Groff (1.19) - 2,360 KB: [http://freshmeat.net/projects/groff/] http://freshmeat.net/projects/groff/ Grub (0.93) - 870 KB: [ftp://alpha.gnu.org/pub/gnu/grub/] ftp://alpha.gnu.org/pub/gnu/grub/ Gzip (1.3.5) - 324 KB: [ftp://alpha.gnu.org/gnu/gzip/] ftp://alpha.gnu.org/gnu/gzip/ Inetutils (1.4.2) - 1,019 KB: [http://freshmeat.net/projects/inetutils/] http://freshmeat.net/projects/ inetutils/ Kbd (1.08) - 801 KB: [http://freshmeat.net/projects/kbd/] http://freshmeat.net/projects/kbd/ Less (381) - 259 KB: [http://freshmeat.net/projects/less/] http://freshmeat.net/projects/less/ LFS-Bootscripts (1.12) - 25 KB: [http://downloads.linuxfromscratch.org/lfs-bootscripts-1.12.tar.bz2] http:// downloads.linuxfromscratch.org/lfs-bootscripts-1.12.tar.bz2 Lfs-Utils (0.3) - 221 KB: [http://www.linuxfromscratch.org/~winkie/downloads/lfs-utils/] http:// www.linuxfromscratch.org/~winkie/downloads/lfs-utils/ Libtool (1.5) - 2,751 KB: [http://freshmeat.net/projects/libtool/] http://freshmeat.net/projects/ libtool/ Linux (2.4.22) - 28,837 KB: [http://freshmeat.net/projects/linux/] http://freshmeat.net/projects/linux/ M4 (1.4) - 310 KB: [http://freshmeat.net/projects/gnum4/] http://freshmeat.net/projects/gnum4/ Make (3.80) - 899 KB: [http://freshmeat.net/projects/gnumake] http://freshmeat.net/projects/gnumake MAKEDEV (1.7) - 8 KB: [http://downloads.linuxfromscratch.org/MAKEDEV-1.7.bz2] http:// downloads.linuxfromscratch.org/MAKEDEV-1.7.bz2 Man (1.5m2) - 196 KB: [http://freshmeat.net/projects/man/] http://freshmeat.net/projects/man/ Man-pages (1.60) - 627 KB: [http://freshmeat.net/projects/man-pages/] http://freshmeat.net/projects/ man-pages/ Modutils (2.4.25) - 215 KB: [http://freshmeat.net/projects/modutils/] http://freshmeat.net/projects/ modutils/ Ncurses (5.3) - 2,019 KB: [http://freshmeat.net/projects/ncurses/] http://freshmeat.net/projects/ ncurses/ Net-tools (1.60) - 194 KB: [http://freshmeat.net/projects/net-tools/] http://freshmeat.net/projects/ net-tools/ Patch (2.5.4) - 182 KB: [http://freshmeat.net/projects/patch/] http://freshmeat.net/projects/patch/ Perl (5.8.0) - 10,765 KB: [http://freshmeat.net/projects/perl/] http://freshmeat.net/projects/perl/ Procinfo (18) - 24 KB: [http://freshmeat.net/projects/procinfo/] http://freshmeat.net/projects/ procinfo/ Procps (3.1.11) - 242 KB: [http://freshmeat.net/projects/procps/] http://freshmeat.net/projects/procps/ Psmisc (21.3) - 259 KB: [http://freshmeat.net/projects/psmisc/] http://freshmeat.net/projects/psmisc/ Sed (4.0.7) - 678 KB: [http://freshmeat.net/projects/sed/] http://freshmeat.net/projects/sed/ Shadow (4.0.3) - 760 KB: [http://freshmeat.net/projects/shadow/] http://freshmeat.net/projects/shadow/ Sysklogd (1.4.1) - 80 KB: [http://freshmeat.net/projects/sysklogd/] http://freshmeat.net/projects/ sysklogd/ Sysvinit (2.85) - 91 KB: [http://freshmeat.net/projects/sysvinit/] http://freshmeat.net/projects/ sysvinit/ Tar (1.13.25) - 1,281 KB: [ftp://alpha.gnu.org/gnu/tar/] ftp://alpha.gnu.org/gnu/tar/ Tcl (8.4.4) - 3,292 KB: [http://freshmeat.net/projects/tcltk/] http://freshmeat.net/projects/tcltk/ Texinfo (4.6) - 1,317 KB: [http://freshmeat.net/projects/texinfo/] http://freshmeat.net/projects/ texinfo/ Util-linux (2.12) - 1,814 KB: [http://freshmeat.net/projects/util-linux/] http://freshmeat.net/projects/ util-linux/ Vim (6.2) - 3,193 KB: [http://freshmeat.net/projects/vim/] http://freshmeat.net/projects/vim/ Zlib (1.1.4) - 144 KB: [http://freshmeat.net/projects/zlib/] http://freshmeat.net/projects/zlib/ Total size of these packages: 134 MB Note File (4.04) may not be available by the time you read this. The master download location is known to remove old versions when new ones are released. Please refer to the corresponding section in Appendix A for an alternate download location. ----------------------------------------------------------------------------- 4.3. Needed patches 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: Bash Patch - 7 KB: [http://www.linuxfromscratch.org/patches/lfs/5.0/bash-2.05b-2.patch] http:// www.linuxfromscratch.org/patches/lfs/5.0/bash-2.05b-2.patch Bison Attribute Patch - 2 KB: [http://www.linuxfromscratch.org/patches/lfs/5.0/bison-1.875-attribute.patch] http://www.linuxfromscratch.org/patches/lfs/5.0/bison-1.875-attribute.patch Coreutils Hostname Patch - 1 KB: [http://www.linuxfromscratch.org/patches/lfs/5.0/ coreutils-5.0-hostname-2.patch] http://www.linuxfromscratch.org/patches/lfs/ 5.0/coreutils-5.0-hostname-2.patch Coreutils Uname Patch - 1 KB: [http://www.linuxfromscratch.org/patches/lfs/5.0/coreutils-5.0-uname.patch] http://www.linuxfromscratch.org/patches/lfs/5.0/coreutils-5.0-uname.patch Ed Mkstemp Patch - 1 KB: [http://www.linuxfromscratch.org/patches/lfs/5.0/ed-0.2-mkstemp.patch] http:/ /www.linuxfromscratch.org/patches/lfs/5.0/ed-0.2-mkstemp.patch Expect Spawn Patch - 6 KB: [http://www.linuxfromscratch.org/patches/lfs/5.0/expect-5.39.0-spawn.patch] http://www.linuxfromscratch.org/patches/lfs/5.0/expect-5.39.0-spawn.patch Gawk Libexecdir Patch - 1 KB: [http://www.linuxfromscratch.org/patches/lfs/5.0/gawk-3.1.3-libexecdir.patch] http://www.linuxfromscratch.org/patches/lfs/5.0/gawk-3.1.3-libexecdir.patch GCC No-Fixincludes Patch - 1 KB: [http://www.linuxfromscratch.org/patches/lfs/5.0/ gcc-3.3.1-no_fixincludes-2.patch] http://www.linuxfromscratch.org/patches/lfs /5.0/gcc-3.3.1-no_fixincludes-2.patch GCC Specs Patch - 10 KB: [http://www.linuxfromscratch.org/patches/lfs/5.0/gcc-3.3.1-specs-2.patch] http://www.linuxfromscratch.org/patches/lfs/5.0/gcc-3.3.1-specs-2.patch GCC Suppress-Libiberty Patch - 1 KB: [http://www.linuxfromscratch.org/patches/lfs/5.0/ gcc-3.3.1-suppress-libiberty.patch] http://www.linuxfromscratch.org/patches/ lfs/5.0/gcc-3.3.1-suppress-libiberty.patch GCC-2 Patch - 16 KB: [http://www.linuxfromscratch.org/patches/lfs/5.0/gcc-2.95.3-2.patch] http:// www.linuxfromscratch.org/patches/lfs/5.0/gcc-2.95.3-2.patch GCC-2 No-Fixincludes Patch - 1 KB: [http://www.linuxfromscratch.org/patches/lfs/5.0/gcc-2.95.3-no-fixinc.patch] http://www.linuxfromscratch.org/patches/lfs/5.0/gcc-2.95.3-no-fixinc.patch GCC-2 Return-Type Patch - 1 KB: [http://www.linuxfromscratch.org/patches/lfs/5.0/ gcc-2.95.3-returntype-fix.patch] http://www.linuxfromscratch.org/patches/lfs/ 5.0/gcc-2.95.3-returntype-fix.patch Glibc Sscanf Patch - 2 KB: [http://www.linuxfromscratch.org/patches/lfs/5.0/glibc-2.3.2-sscanf-1.patch] http://www.linuxfromscratch.org/patches/lfs/5.0/glibc-2.3.2-sscanf-1.patch Grub Gcc33 Patch - 1 KB: [http://www.linuxfromscratch.org/patches/lfs/5.0/grub-0.93-gcc33-1.patch] http://www.linuxfromscratch.org/patches/lfs/5.0/grub-0.93-gcc33-1.patch Kbd More-Programs Patch - 1 KB: [http://www.linuxfromscratch.org/patches/lfs/5.0/ kbd-1.08-more-programs.patch] http://www.linuxfromscratch.org/patches/lfs/5.0 /kbd-1.08-more-programs.patch Man 80-Columns Patch - 1 KB: [http://www.linuxfromscratch.org/patches/lfs/5.0/man-1.5m2-80cols.patch] http://www.linuxfromscratch.org/patches/lfs/5.0/man-1.5m2-80cols.patch Man Manpath Patch - 1 KB: [http://www.linuxfromscratch.org/patches/lfs/5.0/man-1.5m2-manpath.patch] http://www.linuxfromscratch.org/patches/lfs/5.0/man-1.5m2-manpath.patch Man Pager Patch - 1 KB: [http://www.linuxfromscratch.org/patches/lfs/5.0/man-1.5m2-pager.patch] http: //www.linuxfromscratch.org/patches/lfs/5.0/man-1.5m2-pager.patch Ncurses Etip Patch - 1 KB: [http://www.linuxfromscratch.org/patches/lfs/5.0/ncurses-5.3-etip-2.patch] http://www.linuxfromscratch.org/patches/lfs/5.0/ncurses-5.3-etip-2.patch Ncurses Vsscanf Patch - 1 KB: [http://www.linuxfromscratch.org/patches/lfs/5.0/ncurses-5.3-vsscanf.patch] http://www.linuxfromscratch.org/patches/lfs/5.0/ncurses-5.3-vsscanf.patch Net-tools Mii-Tool-Gcc33 Patch - 2 KB: [http://www.linuxfromscratch.org/patches/lfs/5.0/ net-tools-1.60-miitool-gcc33-1.patch] http://www.linuxfromscratch.org/patches /lfs/5.0/net-tools-1.60-miitool-gcc33-1.patch Perl Libc Patch - 1 KB: [http://www.linuxfromscratch.org/patches/lfs/5.0/perl-5.8.0-libc-3.patch] http://www.linuxfromscratch.org/patches/lfs/5.0/perl-5.8.0-libc-3.patch Procps Locale Patch - 1 KB: [http://www.linuxfromscratch.org/patches/lfs/5.0/ procps-3.1.11-locale-fix.patch] http://www.linuxfromscratch.org/patches/lfs/ 5.0/procps-3.1.11-locale-fix.patch Shadow Newgrp Patch - 1 KB: [http://www.linuxfromscratch.org/patches/lfs/5.0/ shadow-4.0.3-newgrp-fix.patch] http://www.linuxfromscratch.org/patches/lfs/ 5.0/shadow-4.0.3-newgrp-fix.patch  Zlib Vsnprintf Patch - 10 KB: [http://www.linuxfromscratch.org/patches/lfs/5.0/zlib-1.1.4-vsnprintf.patch] http://www.linuxfromscratch.org/patches/lfs/5.0/zlib-1.1.4-vsnprintf.patch 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 [http://www.linuxfromscratch.org/patches/] http://www.linuxfromscratch.org/patches/, and pick any additional patches you wish to use. ----------------------------------------------------------------------------- Chapter 5. Constructing a temporary system ----------------------------------------------------------------------------- 5.1. 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. The building of this minimal system is done in two steps: first we build a brand-new and host-independent toolchain (compiler, assembler, linker and libraries), 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. Since the packages compiled here are merely temporary, we don't want them to pollute the soon-to-be LFS system. The key to learning what makes a Linux system work is to know what each package is used for and why the user or the system needs it. For this purpose a short summary of the content of each package is given before the actual installation instructions. For a short description of each program in a package, please refer to the corresponding section in Appendix A. The build instructions assume that you are using the bash shell. There is also a general expectation that you have already unpacked the sources for a package and have performed a cd into the unpacked source directory before issuing the build commands. 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. During the installation of most packages you will see all kinds of compiler warnings scroll by on your screen. These are normal and can be safely 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. Unless told not to, you should normally delete the source and build directories after installing each package -- for cleanness sake and to save space. Before continuing, make sure the LFS environment variable is set up properly by executing the following: 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. ----------------------------------------------------------------------------- 5.2. Toolchain technical notes This section attempts to explain some of the rationale and technical details behind the overall build method. It's not essential that you understand everything here immediately. Most of it will make sense once you have performed an actual build. Feel free to refer back here at any time. The overall goal of Chapter 5 is to provide a sane, temporary environment that we can chroot into, and from which we can produce a clean, trouble-free build of the target LFS system in Chapter 6. Along the way, we attempt to divorce ourselves from the host system as much as possible, and in so doing build a self-contained and self-hosted toolchain. It should be noted that the build process has been designed in such a way so as to minimize the risks for new readers and provide maximum educational value at the same time. In other words, more advanced techniques could be used to build the system. Important Before continuing, you really should be aware of the name of your working platform, often also referred to as the target triplet. For many folks the target triplet will be, for example: i686-pc-linux-gnu. A simple way to determine your target triplet is to run the config.guess script that comes with the source for many packages. Unpack the Binutils sources and run the script: ./ config.guess and note the output. You'll also need to be aware of the name of your platform's dynamic linker, often also referred to as the dynamic loader, not to be confused with the standard linker ld that is part of Binutils. The dynamic linker is provided by Glibc and has the job of finding and loading the shared libraries needed by a program, preparing the program to run and then running it. For most folks, the name of the dynamic linker will be ld-linux.so.2. On platforms that are less prevalent, the name might be ld.so.1 and newer 64 bit platforms might even have something completely different. You should be able to determine the name of your platform's dynamic linker by looking in the /lib directory on your host system. A surefire way is to inspect a random binary from your host system by running: 'readelf -l | grep interpreter' and noting the output. The authoritative reference covering all platforms is in the shlib-versions file in the root of the Glibc source tree. Some key technical points of how the Chapter 5 build method works:   * Similar in principle to cross compiling whereby tools installed into the same prefix work in cooperation and thus utilize a little GNU "magic".   * Careful manipulation of the standard linker's library search path to ensure programs are linked only against libraries we choose.   * Careful manipulation of gcc's specs file to tell the compiler which target dynamic linker will be used. Binutils is installed first because both GCC and Glibc perform various feature tests on the assembler and linker during their respective runs of ./ configure to determine which software features to enable or disable. This is more important than one might first realize. An incorrectly configured GCC or Glibc can result in a subtly broken toolchain where the impact of such breakage might not show up until near the end of the build of a whole distribution. Thankfully, a test suite failure will usually alert us before too much time is wasted. Binutils installs its assembler and linker into two locations, /tools/bin and /tools/$TARGET_TRIPLET/bin. In reality, the tools in one location are hard linked to the other. An important facet of the linker is its library search order. Detailed information can be obtained from ld by passing it the --verbose flag. For example: 'ld --verbose | grep SEARCH' will show you the current search paths and their order. You can see what files are actually linked by ld by compiling a dummy program and passing the --verbose switch. For example: 'gcc dummy.c -Wl,--verbose 2>&1 | grep succeeded' will show you all the files successfully opened during the link. The next package installed is GCC and during its run of ./configure you'll see, for example: checking what assembler to use... /tools/i686-pc-linux-gnu/bin/as checking what linker to use... /tools/i686-pc-linux-gnu/bin/ld This is important for the reasons mentioned above. It also demonstrates that GCC's configure script does not search the $PATH directories to find which tools to use. However, during the actual operation of gcc itself, the same search paths are not necessarily used. You can find out which standard linker gcc will use by running: 'gcc -print-prog-name=ld'. Detailed information can be obtained from gcc by passing it the -v flag while compiling a dummy program. For example: 'gcc -v dummy.c' will show you detailed information about the preprocessor, compilation and assembly stages, including gcc's include search paths and their order. The next package installed is Glibc. The most important considerations for building Glibc are the compiler, binary tools and kernel headers. The compiler is generally no problem as Glibc will always use the gcc found in a $PATH directory. The binary tools and kernel headers can be a little more troublesome. Therefore we take no risks and use the available configure switches to enforce the correct selections. After the run of ./configure you can check the contents of the config.make file in the glibc-build directory for all the important details. You'll note some interesting items like the use of CC="gcc -B/tools/bin/" to control which binary tools are used, and also the use of the -nostdinc and -isystem flags to control the compiler's include search path. These items help to highlight an important aspect of the Glibc package: it is very self-sufficient in terms of its build machinery and generally does not rely on toolchain defaults. After the Glibc installation, we make some adjustments to ensure that searching and linking take place only within our /tools prefix. We install an adjusted ld, which has a hard-wired search path limited to /tools/lib. Then we amend gcc's specs file to point to our new dynamic linker in /tools/lib. This last step is vital to the whole process. As mentioned above, a hard-wired path to a dynamic linker is embedded into every ELF shared executable. You can inspect this by running: 'readelf -l | grep interpreter'. By amending gcc's specs file, we are ensuring that every program compiled from here through the end of Chapter 5 will use our new dynamic linker in /tools/lib. The need to use the new dynamic linker is also the reason why we apply the Specs patch for the second pass of GCC. Failure to do so will result in the GCC programs themselves having the name of the dynamic linker from the host system's /lib directory embedded into them, which would defeat our goal of getting away from the host. During the second pass of Binutils, we are able to utilize the --with-lib-path configure switch to control ld's library search path. From this point onwards, the core toolchain is self-contained and self-hosted. The remainder of the Chapter 5 packages all build against the new Glibc in /tools and all is well. Upon entering the chroot environment in Chapter 6, the first major package we install is Glibc, due to its self-sufficient nature that we mentioned above. Once this Glibc is installed into /usr, we perform a quick changeover of the toolchain defaults, then proceed for real in building the rest of the target Chapter 6 LFS system. ----------------------------------------------------------------------------- 5.2.1. Notes on static linking Most programs have to perform, beside their specific task, many rather common and sometimes trivial operations. These include allocating memory, searching directories, reading and writing files, string handling, pattern matching, arithmetic and many other tasks. Instead of obliging each program to reinvent the wheel, the GNU system provides all these basic functions in ready-made libraries. The major library on any Linux system is Glibc. There are two primary ways of linking the functions from a library to a program that uses them: statically or dynamically. When a program is linked statically, the code of the used functions is included in the executable, resulting in a rather bulky program. When a program is dynamically linked, what is included is a reference to the dynamic linker, the name of the library, and the name of the function, resulting in a much smaller executable. (A third way is to use the programming interface of the dynamic linker. See the dlopen man page for more information.) Dynamic linking is the default on Linux and has three major advantages over static linking. First, you need only one copy of the executable library code on your hard disk, instead of having many copies of the same code included into a whole bunch of programs -- thus saving disk space. Second, when several programs use the same library function at the same time, only one copy of the function's code is required in core -- thus saving memory space. Third, when a library function gets a bug fixed or is otherwise improved, you only need to recompile this one library, instead of having to recompile all the programs that make use of the improved function. If dynamic linking has several advantages, why then do we statically link the first two packages in this chapter? The reasons are threefold: historical, educational, and technical. Historical, because earlier versions of LFS statically linked every program in this chapter. Educational, because knowing the difference is useful. Technical, because we gain an element of independence from the host in doing so, meaning that those programs can be used independently of the host system. However, it's worth noting that an overall successful LFS build can still be achieved when the first two packages are built dynamically. ----------------------------------------------------------------------------- 5.3. Creating the $LFS/tools directory All programs compiled in this chapter will be installed under $LFS/tools 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. If later you wish to search through the binaries of your system to see what files they make use of or link against, then to make this searching easier you may want to choose a unique name. Instead of the simple "tools" you could use something like "tools-for-lfs". Create the required directory by running the following: mkdir $LFS/tools The next step is to create a /tools symlink on your host system. It will point to the directory we just created on the LFS partition: ln -s $LFS/tools / This symlink enables us to compile our toolchain so that it always refers to /tools, meaning that the compiler, assembler and linker will work both in this chapter (when we are still using some tools from the host) and in the next (when we are chrooted to the LFS partition). Note Study the above command closely. It can be confusing at first glance. The ln command has several syntax variations, so be sure to check the ln man page before reporting what you may think is an error. ----------------------------------------------------------------------------- 5.4. Adding the user lfs When logged in as root, 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 lfs and use this one during the installation process. As root, issue the following commands to add the new user: useradd -s /bin/bash -m lfs passwd lfs Now grant this new user lfs full access to $LFS/tools by giving it ownership of the directory: chown lfs $LFS/tools If you made a separate working directory as suggested, give user lfs ownership of this directory too: chown lfs $LFS/sources Next, login as user lfs. This can be done via a virtual console, through a display manager, or with the following substitute user command: su - lfs The "-" instructs su to start a new, clean shell. ----------------------------------------------------------------------------- 5.5. Setting up the environment While logged in as user lfs, issue the following commands to set up a good work environment: cat > ~/.bash_profile << "EOF" set +h umask 022 LFS=/mnt/lfs LC_ALL=POSIX PATH=/tools/bin:$PATH export LFS LC_ALL PATH unset CC CXX CPP LD_LIBRARY_PATH LD_PRELOAD EOF source ~/.bash_profile The set +h command turns off bash's hash function. Normally hashing is a useful feature: bash 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 (make, patch, sed, cp and so forth) will always use the newest available version during the build process. 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. The LFS variable should of course be set to the mount point you chose. 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. We prepend /tools/bin 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. The CC, CXX, CPP, LD_LIBRARY_PATH and LD_PRELOAD environment variables all have the potential to cause havoc with our Chapter 5 toolchain. We therefore unset them to prevent any chance of this happening. Now, after sourcing the just-created profile, we're all set to begin building the temporary tools that will support us in later chapters. ----------------------------------------------------------------------------- 5.6. Installing Binutils-2.14 - Pass 1 Estimated build time: 1.0 SBU Estimated required disk space: 194 MB ----------------------------------------------------------------------------- 5.6.1. Contents of Binutils Binutils is a collection of software development tools containing a linker, assembler and other tools to work with object files and archives. Installed programs: addr2line, ar, as, c++filt, gprof, ld, nm, objcopy, objdump, ranlib, readelf, size, strings and strip Installed libraries: libiberty.a, libbfd.[a,so] and libopcodes.[a,so] ----------------------------------------------------------------------------- 5.6.2. ----------------------------------------------------------------------------- 5.6.3. Binutils Installation Dependencies Binutils depends on: Bash, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Perl, Sed, Texinfo. ----------------------------------------------------------------------------- 5.6.4. ----------------------------------------------------------------------------- 5.6.5. Installation of Binutils It is important that Binutils be the first package to get compiled, because both Glibc and GCC perform various tests on the available linker and assembler to determine which of their own features to enable. Note Even though Binutils is an important toolchain package, we are not going to run the test suite at this early stage. First, the test suite framework is not yet in place and second, the programs from this first pass will soon be overwritten by those installed in the second pass. This package is known to behave badly when you have changed its default optimization flags (including the -march and -mcpu options). Therefore, if you have defined any environment variables that override default optimizations, such as CFLAGS and CXXFLAGS, we recommend unsetting or modifying them when building Binutils. The Binutils documentation recommends building Binutils outside of the source directory in a dedicated build directory: mkdir ../binutils-build cd ../binutils-build Note If you want the SBU values listed in the rest of the book to be of any use, you will have to measure the time it takes to build this package. To achieve this easily, you could do something like: time { ./configure ... && ... && ... && make install; }. Now prepare Binutils for compilation: ../binutils-2.14/configure \ --prefix=/tools --disable-nls The meaning of the configure options:   * --prefix=/tools: This tells the configure script to prepare to install the Binutils programs in the /tools directory.   * --disable-nls: This disables internationalization (a word often shortened to i18n). We don't need this for our static programs and nls often causes problems when linking statically. Continue with compiling the package: make configure-host make LDFLAGS="-all-static" The meaning of the make parameters:   * configure-host: This forces all the subdirectories to be configured immediately. A statically linked build will fail without it. We therefore use this option to work around the problem.   * LDFLAGS="-all-static": This tells the linker that all the Binutils programs should be linked statically. However, strictly speaking, "-all-static" is first passed to the libtool program which then passes "-static" on to the linker. And install the package: make install Now prepare the linker for the "locking in" of Glibc later on: make -C ld clean make -C ld LDFLAGS="-all-static" LIB_PATH=/tools/lib The meaning of the make parameters:   * -C ld clean: This tells the make program to remove all the compiled files, but only in the ld subdirectory.   * -C ld LDFLAGS="-all-static" LIB_PATH=/tools/lib: This option rebuilds everything in the ld subdirectory. Specifying the LIB_PATH makefile variable on the command line allows us to override the default value and have it point to our temporary tools location. The value of this variable specifies the linker's default library search path. You'll see how this preparation is used later on in the chapter. Warning Do not yet remove the Binutils build and source directories. You will need them again in their current state a bit further on in this chapter. ----------------------------------------------------------------------------- 5.7. Installing GCC-3.3.1 - Pass 1 Estimated build time: 4.4 SBU Estimated required disk space: 300 MB ----------------------------------------------------------------------------- 5.7.1. Contents of GCC The GCC package contains the GNU compiler collection, including the C and C++ compilers. Installed programs: c++, cc (link to gcc), cc1, cc1plus, collect2, cpp, g++, gcc, gccbug, and gcov Installed libraries: libgcc.a, libgcc_eh.a, libgcc_s.so, libstdc++.[a,so] and libsupc++.a ----------------------------------------------------------------------------- 5.7.2. ----------------------------------------------------------------------------- 5.7.3. GCC Installation Dependencies GCC depends on: Bash, Binutils, Coreutils, Diffutils, Findutils, Gawk, Gettext, Glibc, Grep, Make, Perl, Sed, Texinfo. ----------------------------------------------------------------------------- 5.7.4. ----------------------------------------------------------------------------- 5.7.5. Installation of GCC Unpack only the GCC-core tarball, as we won't be needing a C++ compiler for the moment. Note Even though GCC is an important toolchain package, we are not going to run the test suite at this early stage. First, the test suite framework is not yet in place and second, the programs from this first pass will soon be overwritten by those installed in the second pass. This package is known to behave badly when you have changed its default optimization flags (including the -march and -mcpu options). Therefore, if you have defined any environment variables that override default optimizations, such as CFLAGS and CXXFLAGS, we recommend unsetting or modifying them when building GCC. The GCC documentation recommends building GCC outside of the source directory in a dedicated build directory: mkdir ../gcc-build cd ../gcc-build Prepare GCC for compilation: ../gcc-3.3.1/configure --prefix=/tools \ --with-local-prefix=/tools \ --disable-nls --enable-shared \ --enable-languages=c The meaning of the configure options:   * --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, thus making 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 further on.   * --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. And install the package: make install As a finishing touch we'll create the /tools/bin/cc 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 -sf gcc /tools/bin/cc ----------------------------------------------------------------------------- 5.8. Installing Linux-2.4.22 headers Estimated build time: 0.1 SBU Estimated required disk space: 186 MB ----------------------------------------------------------------------------- 5.8.1. Contents of Linux The Linux kernel is at the core of every Linux system. It's what makes Linux tick. When a computer is turned on and boots a Linux system, the very first piece of Linux software that gets loaded is the kernel. The kernel initializes the system's hardware components: serial ports, parallel ports, sound cards, network cards, IDE controllers, SCSI controllers and a lot more. In a nutshell the kernel makes the hardware available so that the software can run. Installed files: the kernel and the kernel headers ----------------------------------------------------------------------------- 5.8.2. ----------------------------------------------------------------------------- 5.8.3. Linux Installation Dependencies Linux depends on: Bash, Binutils, Coreutils, Findutils, GCC, Glibc, Grep, Gzip, Make, Modutils, Perl, Sed. ----------------------------------------------------------------------------- 5.8.4. ----------------------------------------------------------------------------- 5.8.5. 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 untarring. Create the include/linux/version.h file: make include/linux/version.h Create the platform-specific include/asm symlink: make symlinks Install the platform-specific header files: mkdir /tools/include/asm cp include/asm/* /tools/include/asm cp -R include/asm-generic /tools/include Install the cross-platform kernel header files: cp -R include/linux /tools/include There are a few kernel header files which make use of the autoconf.h header file. Since we do not yet configure the kernel, we need to create this file ourselves in order to avoid compilation failures. Create an empty autoconf.h file: touch /tools/include/linux/autoconf.h ----------------------------------------------------------------------------- 5.9. Installing Glibc-2.3.2 Estimated build time: 11.8 SBU Estimated required disk space: 800 MB ----------------------------------------------------------------------------- 5.9.1. Contents of Glibc Glibc is the C library that provides the system calls and basic functions such as open, malloc, printf, etc. The C library is used by all dynamically linked programs. Installed programs: catchsegv, gencat, getconf, getent, glibcbug, iconv, iconvconfig, ldconfig, ldd, lddlibc4, locale, localedef, mtrace, nscd, nscd_nischeck, pcprofiledump, pt_chown, rpcgen, rpcinfo, sln, sprof, tzselect, xtrace, zdump and zic Installed libraries: ld.so, libBrokenLocale.[a,so], libSegFault.so, libanl. [a,so], libbsd-compat.a, libc.[a,so], libc_nonshared.a, libcrypt.[a,so], libdl.[a,so], libg.a, libieee.a, libm.[a,so], libmcheck.a, libmemusage.so, libnsl.a, libnss_compat.so, libnss_dns.so, libnss_files.so, libnss_hesiod.so, libnss_nis.so, libnss_nisplus.so, libpcprofile.so, libpthread.[a,so], libresolv.[a,so], librpcsvc.a, librt.[a,so], libthread_db.so and libutil. [a,so] ----------------------------------------------------------------------------- 5.9.2. ----------------------------------------------------------------------------- 5.9.3. Glibc Installation Dependencies Glibc depends on: Bash, Binutils, Coreutils, Diffutils, Gawk, GCC, Gettext, Grep, Make, Perl, Sed, Texinfo. ----------------------------------------------------------------------------- 5.9.4. ----------------------------------------------------------------------------- 5.9.5. Glibc installation Before starting to install Glibc, you must cd into the glibc-2.3.2 directory and unpack Glibc-linuxthreads in that directory, not in the directory where you usually unpack all the sources. Note We are going to run the test suite for Glibc in this chapter. However, it's worth pointing out that running the Glibc test suite here is considered not as important as running it in Chapter 6. This package is known to behave badly when you have changed its default optimization flags (including the -march and -mcpu options). Therefore, if you have defined any environment variables that override default optimizations, such as CFLAGS and CXXFLAGS, we recommend unsetting them when building Glibc. Basically, compiling Glibc in any other way than the book suggests is putting the stability of your system at risk. Though it is a harmless message, the install stage of Glibc will complain about the absence of /tools/etc/ld.so.conf. Fix this annoying little warning with: mkdir /tools/etc touch /tools/etc/ld.so.conf Also, Glibc has a subtle problem when compiled with GCC 3.3.1. Apply the following patch to fix this: patch -Np1 -i ../glibc-2.3.2-sscanf-1.patch The Glibc documentation recommends building Glibc outside of the source directory in a dedicated build directory: mkdir ../glibc-build cd ../glibc-build Next, prepare Glibc for compilation: ../glibc-2.3.2/configure --prefix=/tools \ --disable-profile --enable-add-ons \ --with-headers=/tools/include \ --with-binutils=/tools/bin \ --without-gd The meaning of the configure options:   * --disable-profile: This disables the building of the libraries with profiling information. Omit this option if you plan to do profiling.   * --enable-add-ons: This enables any add-ons that were installed with Glibc, in our case Linuxthreads.   * --with-binutils=/tools/bin and --with-headers=/tools/include: Strictly speaking these switches are not required. But they ensure nothing can go wrong with regard to what kernel headers and Binutils programs get used during the Glibc build.   * --without-gd: This switch ensures that we don't build the memusagestat program, which strangely enough insists on linking against the host's libraries (libgd, libpng, libz, and so forth). 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 Run the test suite: make check The Glibc test suite is highly dependent on certain functions of your host system, in particular the kernel. Additionally, here in this chapter some tests can be adversely affected by existing tools or environmental issues on the host system. Of course, these won't be a problem when we run the Glibc test suite inside the chroot environment of Chapter 6. In general, the Glibc test suite is always expected to pass. However, as mentioned above, some failures are unavoidable in certain circumstances. Here is a list of the most common issues we are aware of:   * The math tests sometimes fail when running on systems where the CPU is not a relatively new genuine Intel or authentic AMD. Certain optimization settings are also known to be a factor here.   * The gettext test sometimes fails due to host system issues. The exact reasons are not yet clear.   * The atime test sometimes fails when the LFS partition is mounted with the noatime option, or due to other file system quirks.   * The shm test might fail when the host system is running the devfs file system but doesn't have the tmpfs file system mounted at /dev/shm due to lack of support for tmpfs in the kernel.   * When running on older and slower hardware, some tests might fail due to test timeouts being exceeded. In summary, don't worry too much if you see Glibc test suite failures here in this chapter. The Glibc in Chapter 6 is the one we'll ultimately end up using so that is the one we would really like to see pass. But please keep in mind, even in Chapter 6 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 on. You can circumvent this stop-start sequence by issuing a make -k check. But if you do that, be sure to log the output so that you can later peruse the log file and examine the total number of failures. Now install the package: 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. We'll install the Glibc locales now: make localedata/install-locales An alternative to running the previous comma