Details on this package are located in Section 6.11.2, “Contents of Binutils.”
Copyright © 1999–2007 Gerard Beekmans
Copyright (c) 1999–2007, 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.
My adventures in Linux began in 1998 when I downloaded and installed my first distribution. After working with it for a while, I discovered issues I definitely would have liked to see improved upon. For example, I didn't like the arrangement of the bootscripts or the way programs were configured by default. I tried a number of alternative distributions to address these issues, yet each had its pros and cons. Finally, I realized that if I wanted full satisfaction from my Linux system, I would have to build my own from scratch.
What does this mean? I resolved not to use pre-compiled packages of any kind, nor CD-ROMs or boot disks that would install basic utilities. I would use my current Linux system to develop my own customized system. This “perfect” Linux system would then have the strengths of various systems without their associated weaknesses. In the beginning, the idea was rather daunting, but I remained committed to the idea that a system could be built that would conform to my needs and desires rather than to a standard that just did not fit what I was looking for.
After sorting through issues such as circular dependencies and compile-time errors, I created a custom-built Linux system that was fully operational and suitable to individual needs. This process also allowed me to create compact and streamlined Linux systems which are faster and take up less space than traditional operating systems. I called this system a Linux From Scratch system, or an LFS system for short.
As I shared my goals and experiences with other members of the Linux community, it became apparent that there was sustained interest in the ideas set forth in my Linux adventures. Such custom-built LFS systems serve not only to meet user specifications and requirements, but also serve as an ideal learning opportunity for programmers and system administrators to enhance their Linux skills. Out of this broadened interest, the Linux From Scratch Project was born.
This Linux From Scratch book provides readers with the background and instruction to design and build custom Linux systems. This book highlights the Linux from Scratch project and the benefits of using this system. Users can dictate all aspects of their system, including directory layout, script setup, and security. The resulting system will be compiled completely from the source code, and the user will be able to specify where, why, and how programs are installed. This book allows readers to fully customize Linux systems to their own needs and allows users more control over their system.
I hope you will have a great time working on your own LFS system, and enjoy the numerous benefits of having a system that is truly your own.
--
Gerard Beekmans
gerard AT linuxfromscratch D0T org
There are many reasons why somebody would want to read this book. The principal reason is to install a Linux system 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 what makes Linux tick, and 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 it allows users to have more control over the system without relying on someone else's Linux implementation. With LFS, you are in the driver's seat and dictate every aspect of the 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, one is often forced to include several programs which are probably never used. These programs waste disk space, or worse, CPU cycles. It is not difficult to build an LFS system of less than 100 megabytes (MB), which is substantially smaller than the majority of existing installations. Does this still sound like a lot of space? A few of us have been working on creating a very small embedded LFS system. We successfully built a system that was specialized to run the Apache web server with approximately 8MB of disk space used. Further stripping could bring this down to 5 MB or less. Try that with a regular distribution! This is only one of the many benefits of designing your own Linux implementation.
We could compare Linux distributions to a hamburger purchased at a fast-food restaurant—you have no idea what might be in what you are eating. LFS, on the other hand, does not give you a hamburger. Rather, LFS provides the recipe to make the exact hamburger desired. This allows users to review the recipe, omit unwanted ingredients, and add your own ingredients to enhance the flavor of the burger. When you are satisfied with the recipe, move on to preparing it. It can be made to exact specifications—broil it, bake it, deep-fry it, or barbecue it.
Another analogy that we can use is that of comparing LFS with a finished house. LFS provides the skeletal plan of a house, but it is up to you to build it. LFS maintains the freedom to adjust plans throughout the process, customizing it to the user's needs and preferences.
An additional 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 desired. It is no longer necessary 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 adequately fixes the problem.
The goal of Linux From Scratch is to build a complete and usable foundation-level system. Readers who do not wish to build their own Linux system from scratch may not benefit from the information in this book. If you only want to know what happens while the computer boots, we recommend the “From Power Up To Bash Prompt” HOWTO located at http://axiom.anu.edu.au/~okeefe/p2b/ or on The Linux Documentation Project's (TLDP) website at http://www.tldp.org/HOWTO/From-PowerUp-To-Bash-Prompt-HOWTO.html. The HOWTO builds a system which is similar to that of this book, but it focuses strictly on creating a system capable of booting to a BASH prompt. Consider your objective. If you wish to build a Linux system while learning along the way, then this book is your best choice.
There are too many good reasons to build your own LFS system to list them all here. This section is only the tip of the iceberg. As you continue in your LFS experience, you will find the power that information and knowledge truly bring.
Building an LFS system is not a simple task. It requires a certain level of existing knowledge of Unix system administration in order to resolve problems, and correctly execute the commands listed. In particular, as an absolute minimum, the reader should already have the ability to use the command line (shell) to copy or move files and directories, list directory and file contents, and change the current directory. It is also expected that the reader has a reasonable knowledge of using and installing Linux software.
Because the LFS book assumes at least this basic level of skill, the various LFS support forums are unlikely to be able to provide you with much assistance; you will find that your questions regarding such basic knowledge will likely go unanswered, or you will simply be referred to the LFS essential pre-reading list.
Before building an LFS system, we recommend reading the following HOWTOs:
Software-Building-HOWTO http://www.tldp.org/HOWTO/Software-Building-HOWTO.html
This is a comprehensive guide to building and installing “generic” Unix software packages under Linux.
The Linux Users' Guide http://www.linuxhq.com/guides/LUG/guide.html
This guide covers the usage of assorted Linux software.
The Essential Pre-Reading Hint http://www.linuxfromscratch.org/hints/downloads/files/essential_prereading.txt
This is an LFS Hint written specifically for users new to Linux. It includes a list of links to excellent sources of information on a wide range of topics. Anyone attempting to install LFS should have an understanding of many of the topics in this hint.
Your host system should have the following software with the minimum versions indicated. This should not be an issue for most modern Linux distributions. Also note that many distributions will place software headers into separate packages, often in the form of “<package-name>-devel” or “<package-name>-dev”. Be sure to install those if your distribution provides them.
Bash-2.05a
Binutils-2.12 (Versions greater than 2.17 are not recommended as they have not been tested)
Bison-1.875
Bzip2-1.0.2
Coreutils-5.0 (or Sh-Utils-2.0, Textutils-2.0, and Fileutils-4.1)
Diffutils-2.8
Findutils-4.1.20
Gawk-3.0
Gcc-3.0.1 (Versions greater than 4.1.2 are not recommended as they have not been tested)
Glibc-2.2.5 (Versions greater than 2.5.1 are not recommended as they have not been tested)
Grep-2.5
Gzip-1.2.4
Linux Kernel-2.6.x (having been compiled with GCC-3.0 or greater)
The reason for the kernel version requirement is that thread-local storage support in Binutils will not be built and the Native POSIX Threading Library (NPTL) test suite will segfault if the host's kernel isn't at least a 2.6.x version compiled with a 3.0 or later release of GCC.
If the host kernel is either earlier than 2.6.x, or it was not compiled using a GCC-3.0 (or later) compiler, you will have to replace the kernel with one adhering to the specifications. There are two methods you can take to solve this. First, see if your Linux vendor provides a 2.6 kernel package. If so, you may wish to install it. If your vendor doesn't offer a 2.6 kernel package, or you would prefer not to install it, then you can compile a 2.6 kernel yourself. Instructions for compiling the kernel and configuring the boot loader (assuming the host uses GRUB) are located in Chapter 8.
Make-3.79.1
Patch-2.5.4
Sed-3.0.2
Tar-1.14
To see whether your host system has all the appropriate versions, run the following:
cat > version-check.sh << "EOF"
#!/bin/bash
# Simple script to list version numbers of critical development tools
bash --version | head -n1 | cut -d" " -f2-4
echo -n "Binutils: "; ld --version | head -n1 | cut -d" " -f3-4
bison --version | head -n1
bzip2 --version 2>&1 < /dev/null | head -n1 | cut -d" " -f1,6-
echo -n "Coreutils: "; chown --version | head -n1 | cut -d")" -f2
diff --version | head -n1
find --version | head -n1
gawk --version | head -n1
gcc --version | head -n1
/lib/libc.so.6 | head -n1 | cut -d" " -f1-7
grep --version | head -n1
gzip --version | head -n1
cat /proc/version
make --version | head -n1
patch --version | head -n1
sed --version | head -n1
tar --version | head -n1
EOF
bash version-check.sh
To make things easier to follow, there are a few typographical conventions used throughout this book. This section contains some examples of the typographical format found throughout Linux From Scratch.
./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) shows screen output,
probably as the result of commands issued. This format 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. Its main purpose is to emphasize important points or items.
http://www.linuxfromscratch.org/
This format is used for hyperlinks both within the LFS community and to external pages. It includes HOWTOs, download locations, and websites.
cat > $LFS/etc/group << "EOF"
root:x:0:
bin:x:1:
......
EOF
This format is used 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 end of file (EOF) is
encountered. Therefore, this entire section is generally typed as
seen.
<REPLACED TEXT>
This format is used to encapsulate text that is not to be typed as seen or for copy-and-paste operations.
[OPTIONAL TEXT]
This format is used to encapsulate text that is optional.
passwd(5)
This format is used to refer to a specific manual page
(hereinafter referred to simply as a “man” page). The number inside parentheses
indicates a specific section inside of man. For example, passwd has two man pages. Per
LFS installation instructions, those two man pages will be
located at /usr/share/man/man1/passwd.1 and /usr/share/man/man5/passwd.5. Both man pages
have different information in them. When the book uses
passwd(5) it is specifically
referring to /usr/share/man/man5/passwd.5. man passwd will print the first
man page it finds that matches “passwd”, which will be /usr/share/man/man1/passwd.1. For this example,
you will need to run man 5
passwd in order to read the specific page being
referred to. It should be noted that most man pages do not have
duplicate page names in different sections. Therefore,
man <program
name> is generally sufficient.
This book is divided into the following parts.
Part I explains a few important notes on how to proceed with the LFS installation. This section also provides meta-information about the book.
Part II describes how to prepare for the building process—making a partition, downloading the packages, and compiling temporary tools.
Part III guides the reader 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 Linux system is the foundation on which other software can be built to expand the system as desired. At the end of this book, there is an easy to use reference listing all of the programs, libraries, and important files that have been installed.
The software used to create an LFS system is constantly being updated and enhanced. Security warnings and bug fixes may become available after the LFS book has been released. To check whether the package versions or instructions in this release of LFS need any modifications to accommodate security vulnerabilities or other bug fixes, please visit http://www.linuxfromscratch.org/lfs/errata/6.3-branch/ before proceeding with your build. You should note any changes shown and apply them to the relevant section of the book as you progress with building the LFS system.
The LFS system will be built by using a previously installed Linux distribution (such as Debian, Mandriva, Red Hat, or SUSE). This existing Linux system (the host) will be used as a starting point to provide necessary programs, including a compiler, linker, and shell, to build the new system. Select the “development” option during the distribution installation to be able to access these tools.
As an alternative to installing a separate distribution onto your machine, you may wish to use the Linux From Scratch LiveCD. The CD works well as a host system, providing all the tools you need to successfully follow the instructions in this book. Additionally, it contains all the source packages, patches and a copy of this book. So once you have the CD, no network connection or additional downloads are necessary. For more information about the LFS LiveCD or to download a copy, visit http://www.linuxfromscratch.org/livecd/.
The LFS LiveCD might not work on newer hardware configurations, failing to boot or failing to detect some devices, like SATA hard drives.
The LFS LiveCD team is working to fix these issues, but they need your help testing it, reporting found problems, and collaborating on the LiveCD development.
Please, send your LFS LiveCD reports or development help collaborations to the LFS LiveCD mailing list.
Chapter 2 of this book describes how to create a new Linux native partition and file system, the place where the new LFS system will be compiled and installed. Chapter 3 explains which packages and patches need to be downloaded to build an LFS system and how to store them on the new file system. Chapter 4 discusses the setup of an appropriate working environment. Please read Chapter 4 carefully as it explains several important issues the reader should be aware of before beginning to work through Chapter 5 and beyond.
Chapter 5 explains 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.
Chapter 5 also shows the user how to build a first pass of the toolchain, including Binutils and GCC (first pass basically means these two core packages will be reinstalled). The next step is to build Glibc, the C library. Glibc will be compiled by the toolchain programs built in the first pass. Then, a second pass of the toolchain will be built. This time, the toolchain will be dynamically linked against the newly built Glibc. The remaining Chapter 5 packages are built using this second pass toolchain. When this is done, the LFS installation process will no longer depend on the host distribution, with the exception of the running kernel.
This effort to isolate the new system from the host distribution may seem excessive, but a full technical explanation is provided in Section 5.2, “Toolchain Technical Notes”.
In Chapter 6, the full LFS system is 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 system does not actually reboot, but instead chroot's because creating a bootable system requires additional work which is not necessary just yet. The major advantage is that “chrooting” allows the builder to continue using the host while LFS is being built. While waiting for package compilation to complete, a user can switch to a different virtual console (VC) or X desktop and continue using the computer as normal.
To finish the installation, the LFS-Bootscripts are set up in Chapter 7, and the kernel and boot loader are set up in Chapter 8. Chapter 9 contains information on furthering the LFS experience beyond this book. After the steps in this book have been implemented, the computer will be ready to reboot into the new LFS system.
This is the process in a nutshell. Detailed information on each step is discussed in the following chapters and package descriptions. Items that may seem complicated will be clarified, and everything will fall into place as the reader embarks on the LFS adventure.
Below is a list of package updates made since the previous release of the book.
Upgraded to:
Autoconf 2.61
Automake 1.10
Bash 3.2
Berkeley DB 4.5.20
Binutils 2.17
Bison 2.3
Bzip2 1.0.4
Coreutils 6.9
E2fsprogs 1.40.2
File 4.21
Findutils 4.2.31
GCC 4.1.2
Gettext 0.16.1
Glibc 2.5.1
Groff 1.18.1.4
Gzip 1.3.12
IANA-Etc 2.20
Inetutils 1.5
IPRoute2 2.6.20-070313
Less 406
LFS-Bootscripts 20070730
Libtool 1.5.24
Linux 2.6.22.1
M4 1.4.10
Make 3.81
Man-pages 2.63
Ncurses 5.6
Procps 3.2.7
Psmisc 22.5
Readline 5.2
Shadow 4.0.18.1
Tar 1.18
TCL 8.4.15
Texinfo 4.9
Udev 113
udev-config-20070731
Vim 7.1
Added:
bash-3.2-fixes-5.patch
db-4.5.20-fixes-1.patch
inetutils-1.5-no_server_man_pages-2.patch
ncurses-5.6-coverity_fixes-1.patch
readline-5.2-fixes-3.patch
util-linux-2.12r-lseek-1.patch
vim-7.1-fixes-1.patch
Removed:
bash-3.1-fixes-8.patch
db-4.4.20-fixes-1.patch
glibc-2.3.6-inotify-1.patch
glibc-2.3.6-linux_types-1.patch
gzip-1.3.5-security_fixes-1.patch
inetutils-gcc4_fixes-3.patch
inetutils-no_server_man_pages-1.patch
less-394-signal_fix-1.patch
linux-2.6.17.13-utf8_input-1.patch
Linux-libc-headers 2.6.12.0
ncurses-5.5-fixes-1.patch
readline-5.1-fixes-3.patch
tar-1.15.1-gcc4_fix_tests-1.patch
tar-1.15.1-security_fixes-1.patch
tar-1.15.1-sparse_fix-1.patch
vim-7.0-fixes-7.patch
This is version 6.3-20070731 of the Linux From Scratch book, dated July 31, 2007. If this book is more than six months old, a newer and better version is probably already available. To find out, please check one of the mirrors via http://www.linuxfromscratch.org/mirrors.html.
Below is a list of changes made since the previous release of the book.
Changelog Entries:
2007-07-31
[dnicholson] - Updated to glibc-2.5.1.
[dnicholson] - Updated udev-config rules to 20070731 to work with Linux-2.6.22.
2007-07-30
[dnicholson] - Updated LFS-Bootscripts to 20070730 and added the description for the new consolelog script.
2007-07-26
[bdubbs] - Adjust grep patteren in Ch. 6 gcc to only match desired output.
2007-07-24
[dnicholson] - Fix the Ncurses' library install to remove a symbolic link before writing a linker script to that location. Reported by Lieven De Keyzer.
[bdubbs] - Created LFS 6.3-rc-1.
[dnicholson] - Remove inconsistent uses of && from the book.
2007-07-23
[bdubbs] - Upgrade to Man-Pages-2.63, fixes #2050.
[dnicholson] - Added `echo' to the Essential Symlinks section as it is needed for the Glibc testsuite.
[dnicholson] - Added a known failing test to the Ch. 6 Glibc page.
2007-07-18
[dnicholson] - Described the configuration of the consolelog bootscript.
2007-07-17
[matthew] - Upgrade to Man-Pages-2.62, fixes #2049.
[matthew] - Upgrade to M4-1.4.10, fixes #2048.
[matthew] - Upgrade to Linux-2.6.22.1, fixes #2044.
[matthew] - Upgrade to E2fsprogs-1.40.2, fixes #2042. Remove the --disable-evms configure parameter as it is no longer recognised by the configure script.
2007-07-14
[dnicholson] - Updated the Glibc Branch Update patch to a new snapshot from upstream.
[dnicholson] - Made the Linux API Headers install safer by using an intermediate directory.
2007-07-06
[manuel] - Updated the stylesheets and Makefile to use the new XSL code and Fop-0.93.
2007-06-30
[matthew] - Add upstream patches for Vim.
[matthew] - Upgrade to Udev-113, fixes #2040.
[matthew] - Upgrade to Texinfo-4.9, fixes #2041.
[matthew] - Upgrade to Tar-1.18, fixes #2039.
[matthew] - Upgrade to Libtool-1.5.24, fixes #2038.
[matthew] - Upgrade to Less-406, fixes #2036.
[alexander] - Updated inetutils MD5 sum. Upstream has re-released the tarball with the only changes being relicensing under GPLv3 or later, and re-autotooling.
2007-06-29
[alexander] - Use stable download location for Man-Pages.
2007-06-28
[dnicholson] - Upgrade to Man-Pages-2.60, fixes #2035.
2007-06-17
2007-06-12
2007-06-10
2007-06-06
[manuel] - Adjusted locale settings for Bash testsuite run and kernel make menuconfig command. Fixes #1938.
2007-06-05
2007-05-13
2007-05-07
[dnicholson] - Fixed the toolchain sanity check after GCC to reference the /usr/local/include directory. Thanks to David Murphy for the report.
2007-05-05
[matthew] - Incorporate latest upstream patches for Vim.
[matthew] - Upgrade to Udev-110. Fixes #1992.
[matthew] - Incorporate latest upstream patches for Readline.
[matthew] - Upgrade to Psmisc-22.5. Fixes #1991.
[matthew] - Add a patch from upstream to fix issues in Ncurses found by the Coverity static code analysis tool. Fixes #1995.
[matthew] - Upgrade to Man-pages-2.46. Fixes #1994.
[matthew] - Upgrade to Linux-2.6.21.1. Fixes #1993.
[matthew] - Incorporate latest upstream patches for Bash.
2007-04-20
[dnicholson] - Upgrade to LFS-Bootscripts-20070420.
2007-04-16
[matthew] - Increase the version of Bison required on host systems to 1.875. Bash doesn't work correctly with versions less than that. Fixes #1977.
[matthew] - Change all references to /etc/adjtime in the Util-Linux
sources to /var/lib/hwclock/adjtime.
Previously, only hwclock/hwclock.c was changed,
which meant that man pages contained references to
the non-FHS compliant location. Fixes #1984.
[matthew] - Upgrade to Udev-108. Fixes #1976.
[matthew] - Upgrade to Man-pages-2.44. Fixes #1987.
[matthew] - Upgrade to Man-db-2.4.4. Fixes #1975.
[matthew] - Upgrade to M4-1.4.9. Fixes #1983.
[matthew] - Upgrade to Linux-2.6.20.7. Fixes #1986.
[matthew] - Upgrade to Gzip-1.3.12. Fixes #1989.
[matthew] - Remove File's reg_startend patch. It is not necessary on Glibc-based systems. Thanks to Greg Schafer for the report.
[matthew] - Upgrade to Coreutils-6.9. Fixes #1982.
2007-04-03
[jhuntwork] - Install su from coreutils in chapter 5 as su-tools. Use su-tools to run test suites from coreutils and bash as user nobody. Fixes #1877.
2007-04-01
[jhuntwork] - Upgraded to linux-2.6.20.4. Updated linux-headers instructions in chapter 5 to match instructions in chapter 6. The INSTALL_HDR_PATH is no longer forcibly removed.
2007-03-27
[dnicholson] - Fixed a typo in the readjusting section. Reported by Steve Crosby.
2007-03-24
[dnicholson] - Upgrade the Bash fixes patch to include the latest 011-015 patches from upstream.
[dnicholson] - Upgrade the Readline fixes patch to include the latest 002 patch from upstream.
2007-03-23
[dnicholson] - Don't install the kernel headers in
/usr/include/scsi as
the ones provided by Glibc are preferred.
[dnicholson] - Force ldd to use /bin/bash since it contains Bash-specific syntax.
[dnicholson] - When readjusting the GCC specs file, ensure that GCC will search for the system headers in /usr/include. An addition to the toolchain sanity checks has been made to test this. This fix originates from DIY Linux.
[dnicholson] - Included the branch update patch for the temporary Glibc in Chapter 5 to help minimize differences with the final Glibc.
2007-03-21
[manuel] - Updated book sources to use DocBook-XML DTD 4.5.
2007-03-19
[matthew] - Change the default home directory for
new users and do not create mail spool files for
them. Add a mail
group so that if Shadow is configured to create
mail spool files for new users, it can do so
without issuing a warning.
[matthew] - Upgrade to Shadow-4.0.18.1. Fixes #1850
[matthew] - Upgrade to Linux-2.6.20.3. Fixes #1971
[matthew] - Upgrade to IPRoute2-2.6.20-070313. Fixes #1974
[matthew] - Upgrade the Bash fixes patch to include the latest patch from upstream. Fixes #1973
2007-03-14
[dnicholson] - Force the host's linker to be used throughout Binutils-Pass1 and GCC-Pass1. This makes the build more robust since the host's compiler may not be compatible with the linker installed in Binutils-Pass1, such as on newer Fedora hosts. Fix originates from DIY Linux.
2007-03-04
[matthew] - Make mention of the Ncurses testsuite. Fixes #1954
[matthew] - Upgrade to Vim-7.0-fixes-15.patch which includes all upstream patches up to 206.
[matthew] - Upgrade to Udev-106 and udev-config-20070304. Fixes #1969
[matthew] - Upgrade to Findutils-4.2.30. Fixes #1967
[matthew] - Upgrade to File-4.20. Fixes #1968
2007-03-1
[jhuntwork] - Minor grammatical changes. Move some warnings and notices to appear before affected commands.
2007-02-25
[manuel] - Removed M4 build from Chapter05. No other packages builts before the build of M4 in chapter06 depends on M4.
2007-02-24
[manuel] - Removed obsolete warning about reinstalling Bzip2. Thanks to Chris Staub for the report and patch.
[manuel] - Removed chmod and chown commands from linux headers installation. The headers are now installed with the proper permissions. Fixes #1965
[matthew] - Upgrade to Linux-2.6.20.1. Fixes #1964
[matthew] - Add an upstream patch for Glibc. Fixes #1930
[matthew] - Upgrade to GCC-4.1.2. Fixes #1960
[matthew] - Add an upstream patch for Berkeley-DB. Fixes #1961
[dnicholson] - Added missing command descriptions for cpan and prove from the Perl package. Reported by Leonhard Landrock.
2007-02-23
[dnicholson] - Removed /usr/local/man lines from man_db.conf to prevent redundant results. Reported by Chris Staub.
[dnicholson] - Applied a patch from Chris Staub to fix some commands and text on the kernel file systems, E2fsprogs and Autoconf pages.
[dnicholson] - Dropped the -D switch from the Udev documentation install command since it is already created by udev-config. Reported by Chris Staub.
[dnicholson] - Corrected the text about Udev not installing any configuration files. Reported by Chris Staub.
[dnicholson] - Removed the text suggesting that you can edit the specs file by hand in the toolchain adjustment since it's only generated if you run the previous commands. Reported by Chris Staub.
2007-02-20
[bryan] - Add a comment about CD symlinks possibly not matching the host in section 7.12.2. Should fix the rest of #1963.
2007-02-18
[bryan] - Fix obsolete syntax used in the example Udev rules in section 7.12.2. Fixes the easy part of #1963. Also re-add the note about the backslash at the end of the udev rule lines.
2007-02-17
[bryan] - Use upstream's rule_generator rules exclusively for NIC naming, and generate the rules before configuring the network script, so the user knows what NIC names to use. Fixes the rest of #1912.
[bryan] - Change from writing CD symlink rules files directly to configuring the file installed by Udev's rule_generator. Fixes part of #1912.
[bryan] - Update contents of lfs-bootscripts.
2007-02-09
[matthew] - Move readlink to
/bin because
sysreadlink in Udev's
shell functions may call it before /usr has been mounted. Fixes
#1913
[matthew] - Remove some chmod and chown commands from DB, NCurses and Readline as they are no longer required with recent upstream versions. Fixes #1953
[matthew] - Upgrade to Udev-105. Fixes #1949
[matthew] - Upgrade to Gzip-1.3.11. Fixes #1951
2007-02-07
[ken] - Upgrade to Linux-2.6.20. Fixes #1950.
2007-02-03
[bryan] - Update to lfs-bootscripts-20070203. Fixes both #1948 and the udev_retry script.
2007-01-31
[matthew] - Add verbose flags when untarring the glibc-libidn and udev-config tarballs. Fixes #1932.
[matthew] - Do not set/export INPUTRC anymore, as it is not required after upgrading to Readline-5.2. Fixes #1942. Thanks to Alexander Patrakov for the report and fix.
[matthew] - Include a patch from the Readline maintainer to fix a multibyte-related issue. Fixes #1945
[matthew] - Include more upstream fixes from the Bash maintainer in bash-3.2-fixes-2.patch
[matthew] - Upgrade to Udev-104. Fixes #1941
[matthew] - Upgrade to Ncurses-5.6. Fixes #1940
[matthew] - Upgrade to Linux-2.6.19.2. Fixes #1928
[matthew] - Upgrade to Iproute2-2.6.19-061214. Fixes #1936
[matthew] - Upgrade to Gzip-1.3.10. Fixes #1924
[matthew] - Upgrade to Gettext-0.16.1. Fixes #1925
[matthew] - Upgrade to Findutils-4.2.29. Fixes #1923.
[matthew] - Upgrade to File-4.19. Fixes #1946.
[matthew] - Upgrade to Coreutils-6.7. Fixes #1934.
[matthew] - Upgrade to Bzip2-1.0.4. Fixes #1943.
2007-01-13
2006-12-09
[bryan] - Fix /etc/passwd entry for "nobody" user in chapter 6. Fixes #1931; thanks to Robert Connolly for the report.
2006-12-01
[matthew] - Fix an ICA breakage in E2fsprogs. Sed
needs to be built before E2fsprogs and a hardcoded
reference to /bin/rm
needs to be changed to point to /tools/bin/rm instead. Thanks to
Greg Schafer for the report and fix.
2006-11-25
[jhuntwork] - Add a cautionary note to the end of chapter 5. Archiving of the temporary tools for future use should take place before starting chapter 6. Fixes #1879
[matthew] - Move mv from
/usr/bin to
/bin again. The
upgrade to Coreutils-6.6 mistakenly removed it from
the list of files to be moved. Thanks to Chris
Staub for the report.
[matthew] - Prevent Inetutils from building and installing ifconfig as LFS uses ip to configure network interfaces. Thanks to Marty Jack for the report and the fix. Fixes #1914
[jhuntwork] - Fix potential corruption of the testsuite tools by forcing expect to always use /bin/stty and not /usr/local/bin/stty. Fixes #1892
[matthew] - Upgrade to Man-pages-2.42. Fixes #1922
[matthew] - Upgrade to Inetutils-no_server_man_pages-2.patch. This removes the last of the unwanted man pages (rexecd.8). Thanks to Joe Ciccone for the report and the updated patch. Fixes #1915
[jhuntwork] - Added 'make headers_install' to chapter 5 Linux Headers for the educational value and in preparation of changes in Linux-2.6.19. See this thread.
[matthew] - Upgrade to M4-1.4.8. Fixes 1920
[matthew] - Upgrade to Linux-2.6.18.3. Fixes #1911
[matthew] - chapter08/kernel.xml: Reworded the warning about overwriting sanitized kernel headers rather than raw headers, so as to avoid mentioning the now obsolete Linux-Libc-Headers package. Fixes #1917
[matthew] - Upgrade to IANA-Etc-2.20. Fixes #1916
[matthew] - Upgrade to File-4.18. Fixes #1910
[matthew] - Upgrade to Coreutils-6.6. Fixes #1919
[matthew] - Add Bison to the host requirements as it is required by bash-3.2-fixes-5.patch in chapter 5 (Fixes #1863).
[matthew] - Use all 5 of the patches currently supplied by the upstream maintainers of Bash.
[matthew] - Upgrade to Autoconf-2.61. Fixes #1918.
2006-11-24
[jhuntwork] - Simplified the installation of Linux Headers in Chapter 5.
2006-11-10
[bryan] - Use 70-persistent-*.rules for custom symlinks and NIC naming, and add ENV{GENERATED} to the CD symlink rule. Gets #1912 closer to really being fixed.
2006-11-05
[bryan] - Delete the persistent-net-generator rules file if bus-position-based persistence is going to be used. Fixes #1912.
2006-11-03
[matthew] - Use version entities from packages.ent rather than
hardcoded values in the note in chapter03/packages.xml. Remove
the warning about potential incompatibilities with
the bootscripts. Thanks to Rainer Wirtz for the
report.
2006-10-29
[matthew] - Add verbose flags to some commands in Util-Linux and Vim. Thanks to Robert Connolly for the report.
[matthew] - Upgrade to Vim-7.0-fixes-14.patch. Drop the "spellfile" fix as it was applied upstream as patch 076.
2006-10-28
[matthew] - Upgrade to TCL-8.4.14.
[matthew] - Upgrade to Tar-1.16, including dropping the now unnecessary "gcc4", "security", and "sparse" patches.
[matthew] - Upgrade to Readline-5.2, including dropping the now unnecessary "fixes" patch.
[matthew] - Upgrade to Man-Pages-2.41.
[matthew] - Upgrade to Linux-2.6.18.1.
[matthew] - Fix a bug in Less whereby the
sigset_t type is not
detected by the configure script,
which causes sigsetmask to be used instead of
the preferred sigprocmask function. Thanks to
Robert Connolly for the report and patch.
[matthew] - Upgrade to IPRoute2-2.6.18-20061002.
[matthew] - Upgrade to Inetutils-1.5, including dropping the now unnecessary "GCC 4 fixes" patch.
[matthew] - Upgrade to Groff-1.18.1.4.
[matthew] - Upgrade to Gettext-0.16.
[matthew] - Upgrade to Berkeley DB-4.5.20, including dropping the now unnecessary "fixes" patch.
[matthew] - Upgrade to Coreutils-6.4.
[matthew] - Upgrade to Bash-3.2, including dropping the current "fixes" patch and adding a patch from upstream that fixes a bug when parsing comments.
[matthew] - Upgrade to Automake-1.10.
2006-10-23
[bryan] - Add an explanation of how to discover PCI bus locations for network devices. Fixes #1904.
2006-10-21
[bryan] - Upgrade to udev-103.
[bryan] - Upgrade to udev-config-20061021, install its doc files.
[bryan] - Install common rules from udev package.
2006-10-15
[dnicholson] - Fixed console setup page to reference the correct location for the kbd data. Thanks to Norman Urs Baier for reporting the issue.
[bryan] - Upgrade to udev-102, remove patch.
[bryan] - Upgrade to udev-config-20061014.
2006-10-05
[bryan] - Add udev-101-fix-sas-path_id-1.patch.
[bryan] - Update udev-config for Linux-2.6.18. This version also contains the new doc/ subdirectory, with explanations of most of the rules.
2006-10-02
[matthew] - Upgrade to Texinfo-4.8a.
[matthew] - Updated the text regarding UTF-8 support in the latest version of Linux. Thanks to Alexander Patrakov for the patch.
[matthew] - Remove Linux-Libc-Headers, replacing it with the "make headers_install" target now available in the upstream kernel sources.
[matthew] - Upgrade to Udev-101.
[matthew] - Upgrade to Psmisc-22.3.
[matthew] - Upgrade to M4-1.4.7.
[matthew] - Upgrade to Linux-2.6.18.
[matthew] - Upgrade to Glibc-2.5.
[matthew] - Upgrade to Coreutils-6.3.
2006-09-23
[bryan] - Fixed typo in udev-100 instructions (extra/ should be extras/). Thanks to Balazs Parkanyi for the heads-up.
2006-09-22
[bryan] - Rewrote the notes in sections 7.12.1 and 7.13.1 to explicitly mention that the redirections rely on not quoting EOF. Fixes #1883.
2006-09-20
[bryan] - Updated udev-config for udev-098 and above.
[dnicholson] - Changed note about using newer Linux than in the book to reflect current versions.
2006-09-18
[dnicholson] - Added symlinks to the temporary libstdc++ in the Essential Symlinks section. These are needed by Glibc-2.4.
2006-09-17
[dnicholson] - Updated to Glibc-2.4. Added the iconv fix patch and removed the decprecated linux types and inotify syscall patches. Thanks to Matthew Burgess and Bryan Kadzban for textual suggestions.
2006-09-09
[matthew] - Fix non-POSIX syntax in gzexe's calls to tail. Fixes #1876. Thanks to Robert Connolly for the report.
[matthew] - Upgrade to linux-2.6.17.13.
[matthew] - Upgrade to m4-1.4.6.
2006-09-06
[bryan] - Change the sed applied to sysvinit, to hopefully be more clear (explicitly mention /etc/inittab).
2006-08-31
[matthew] - Remove spurious curly braces from the example /etc/resolv.conf. Fixes #1870.
2006-08-24
[matthew] - Remove the supposed fix for a buffer overflow in Coreutils, as it has been fixed upstream.
2006-08-17
[matthew] - Simplified the command that adjusts GCC's specs file. Fixes #1837. Thanks to Robery Connolly.
[matthew] - Noted devfs' removal from the kernel. Thanks to Peter Ennis.
[matthew] - Upgrade to linux-2.6.17.8.
[matthew] - Upgrade to udev-097.
[matthew] - Upgrade to findutils-4.2.28.
[matthew] - Upgrade to man-pages-2.39.
[matthew] - Fix autoconf's testsuite, which broke after upgrading to m4-1.4.5. Thanks to Greg Schafer for the report.
[matthew] - Fix a buffer overrun in m4-1.4.5 which causes two of its tests to fail. Thanks to Greg Schafer for the report.
2006-08-08
[dnicholson] - Minor text updates to the Vim page. Thanks to Peter Ennis for the report.
2006-08-05
[matthew] - Add a link to the location of Shadow's previous versions.
2006-08-03
[manuel] - Ported updates from 6.2 branch.
2006-07-31
[matthew] - Upgrade to shadow-4.0.17.
[matthew] - Upgrade to procps-3.2.7.
[matthew] - Upgrade to man-pages-2.36.
[matthew] - Upgrade to make-3.81.
[matthew] - Upgrade to m4-1.4.5.
[matthew] - Upgrade to gettext-0.15.
[matthew] - Upgrade to gcc-4.1.1.
[matthew] - Upgrade to coreutils-5.97.
[matthew] - Upgrade to bison-2.3.
[matthew] - Upgrade to binutils-2.17.
[matthew] - Upgrade to autoconf-2.60.
LFS 6.2 released August 3, 2006.
If during the building of the LFS system you encounter any errors, have any questions, or think there is a typo in the book, please start by consulting the Frequently Asked Questions (FAQ) that is located at http://www.linuxfromscratch.org/faq/.
The linuxfromscratch.org server
hosts a number of mailing lists used for the development of
the LFS project. These lists include the main development and
support lists, among others. If the FAQ does not solve the
problem you are having, the next step would be to search the
mailing lists at http://www.linuxfromscratch.org/search.html.
For information on the different lists, how to subscribe, archive locations, and additional information, visit http://www.linuxfromscratch.org/mail.html.
Several members of the LFS community offer assistance on our
community Internet Relay Chat (IRC) network. Before using
this support, please make sure that your question is not
already answered in the LFS FAQ or the mailing list archives.
You can find the IRC network at irc.linuxfromscratch.org. The support channel is
named #LFS-support.
For additional information on the packages, useful tips are available in the LFS Package Reference page located at http://www.linuxfromscratch.org/~matthew/LFS-references.html.
The LFS project has a number of world-wide mirrors to make accessing the website and downloading the required packages more convenient. Please visit the LFS website at http://www.linuxfromscratch.org/mirrors.html for a list of current mirrors.
If an issue or a question is encountered while working through this book, check the FAQ page at http://www.linuxfromscratch.org/faq/#generalfaq. Questions are often already answered there. If your question is not answered on this page, try to find the source of the problem. The following hint will give you some guidance for troubleshooting: http://www.linuxfromscratch.org/hints/downloads/files/errors.txt.
If you cannot find your problem listed in the FAQ, search the mailing lists at http://www.linuxfromscratch.org/search.html.
We also have a wonderful LFS community that is willing to offer assistance through the mailing lists and IRC (see the Section 1.4, “Resources” section of this book). However, we get several support questions every day and many of them can be easily answered by going to the FAQ and by searching the mailing lists first. So, for us to offer the best assistance possible, you need to do some research on your own first. That allows us to focus on the more unusual support needs. If your searches do not produce a solution, please include all relevant information (mentioned below) in your request for help.
Apart from a brief explanation of the problem being experienced, the essential things to include in any request for help are:
The version of the book being used (in this case 6.3-20070731)
The host distribution and version being used to create LFS
The package or section the problem was encountered in
The exact error message or symptom being received
Note whether you have deviated from the book at all
Deviating from this book does not mean that we will not help you. After all, LFS is about personal preference. Being upfront about any changes to the established procedure helps us evaluate and determine possible causes of your problem.
If something goes wrong while running the configure script, review
the config.log file. This file
may contain errors encountered during configure which were not
printed to the screen. Include the relevant lines if you need to ask
for help.
Both the screen output and the contents of various files are useful in determining the cause of compilation problems. The screen output from the configure script and the make run can be helpful. It is not necessary to include the entire output, but do include enough of the relevant information. Below is an example of the type of information to include from the 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 2In this case, many people would just include the bottom section:
make [2]: *** [make] Error 1This is not enough information to properly diagnose the problem because it only notes that something went wrong, not what went wrong. The entire section, as in the example above, is what should be saved because it includes the command that was executed and the associated error message(s).
An excellent article about asking for help on the Internet is available online at http://catb.org/~esr/faqs/smart-questions.html. Read and follow the hints in this document to increase the likelihood of getting the help you need.
In this chapter, the partition which will host the LFS system is prepared. We will create the partition itself, create a file system on it, and mount it.
Like most other operating systems, LFS is usually installed on a dedicated partition. The recommended approach to building an LFS system is to use an available empty partition or, if you have enough unpartitioned space, to create one. However, an LFS system (in fact even multiple LFS systems) may also be installed on a partition already occupied by another operating system and the different systems will co-exist peacefully. The document http://www.linuxfromscratch.org/hints/downloads/files/lfs_next_to_existing_systems.txt explains how to implement this, whereas this book discusses the method of using a fresh partition for the installation.
A minimal system requires a partition of around 1.3 gigabytes (GB). This is enough to store all the source tarballs and compile the packages. However, if the LFS system is intended to be the primary Linux system, additional software will probably be installed which will require additional space (2-3 GB). The LFS system itself will not take up this much room. A large portion of this requirement is to provide sufficient free temporary storage. Compiling packages can require a lot of disk space which will be reclaimed after the package is installed.
Because there is not always enough Random Access Memory (RAM)
available for compilation processes, it is a good idea to use a
small disk partition as swap
space. This is used by the kernel to store seldom-used data and
leave more memory available for active processes. The
swap partition for an LFS
system can be the same as the one used by the host system, in
which case it is not necessary to create another one.
Start a disk partitioning program such as cfdisk or fdisk with a command line
option naming the hard disk on which the new partition will be
created—for example /dev/hda for the primary Integrated Drive
Electronics (IDE) disk. Create a Linux native partition and a
swap partition, if needed.
Please refer to cfdisk(8) or
fdisk(8) if you do not yet know
how to use the programs.
Remember the designation of the new partition (e.g.,
hda5). This book will refer to
this as the LFS partition. Also remember the designation of the
swap partition. These names
will be needed later for the /etc/fstab file.
Now that a blank partition has been set up, the file system can
be created. The most widely-used system in the Linux world is
the second extended file system (ext2), but with newer high-capacity hard
disks, journaling file systems are becoming increasingly
popular. The third extended filesystem (ext3) is a widely used enhancement to
ext2, which adds journalling
capabilities and is compatible with the E2fsprogs utilities. We
will create an ext3 file
system. Instructions for creating other file systems can be
found at
http://www.linuxfromscratch.org/blfs/view/svn/postlfs/filesystems.html.
To create an ext3 file system
on the LFS partition, run the following:
mke2fs -jv /dev/<xxx>
Replace <xxx>
with the name of the LFS partition (hda5 in our previous example).
Some host distributions use custom features in their filesystem creation tools (E2fsprogs). This can cause problems when booting into your new LFS in Chapter 9, as those features will not be supported by the LFS-installed E2fsprogs; you will get an error similar to “unsupported filesystem features, upgrade your e2fsprogs”. To check if your host system uses custom enhancements, run the following command:
debugfs -R feature /dev/<xxx>
If the output contains features other than has_journal, dir_index, filetype, large_file, resize_inode, sparse_super or needs_recovery, then your host system may
have custom enhancements. In that case, to avoid later
problems, you should compile the stock E2fsprogs package and
use the resulting binaries to re-create the filesystem on
your LFS partition:
cd /tmp
tar -xjvf /path/to/sources/e2fsprogs-1.40.2.tar.bz2
cd e2fsprogs-1.40.2
mkdir -v build
cd build
../configure
make #note that we intentionally don't 'make install' here!
./misc/mke2fs -jv /dev/<xxx>
cd /tmp
rm -rfv e2fsprogs-1.40.2
If you are using an existing swap partition, there is no need to format
it. If a new swap partition was
created, it will need to be initialized with this command:
mkswap /dev/<yyy>
Replace <yyy>
with the name of the swap
partition.
Now that a file system has been created, the partition needs to
be made accessible. In order to do this, the partition needs to
be mounted at a chosen mount point. For the purposes of this
book, it is assumed that the file system is mounted under
/mnt/lfs, but the directory
choice is up to you.
Choose a mount point and assign it to the LFS environment variable by running:
export LFS=/mnt/lfs
Next, create the mount point and mount the LFS file system by running:
mkdir -pv $LFS
mount -v -t ext3 /dev/<xxx> $LFS
Replace <xxx>
with the designation of the LFS partition.
If using multiple partitions for LFS (e.g., one for
/ and another for /usr), mount them using:
mkdir -pv $LFS mount -v -t ext3 /dev/<xxx>$LFS mkdir -v $LFS/usr mount -v -t ext3 /dev/<yyy>$LFS/usr
Replace <xxx>
and <yyy> with
the appropriate partition names.
Ensure that this new partition is not mounted with permissions
that are too restrictive (such as the nosuid, nodev, or
noatime options). Run the
mount command
without any parameters to see what options are set for the
mounted LFS partition. If nosuid,
nodev, and/or noatime are set, the partition will need to be
remounted.
If you are using a swap
partition, ensure that it is enabled using the swapon command:
/sbin/swapon -v /dev/<zzz>
Replace <zzz>
with the name of the swap
partition.
Now that there is an established place to work, it is time to download the packages.
This chapter includes a list of packages that need to be downloaded in order to build a basic Linux system. The listed version numbers correspond to versions of the software that are known to work, and this book is based on their use. We highly recommend against using newer versions because the build commands for one version may not work with a newer version. The newest package versions may also have problems that require work-arounds. These work-arounds will be developed and stabilized in the development version of the book.
Download locations may not always be accessible. If a download location has changed since this book was published, Google (http://www.google.com/) provides a useful search engine for most packages. If this search is unsuccessful, try one of the alternative means of downloading discussed at http://www.linuxfromscratch.org/lfs/packages.html.
Downloaded packages and patches will need to be stored
somewhere that is conveniently available throughout the entire
build. A working directory is also required to unpack the
sources and build them. $LFS/sources can be used both as the place to
store the tarballs and patches and as a working directory. By
using this directory, the required elements will be located on
the LFS partition and will be available during all stages of
the building process.
To create this directory, execute the following command, as
user root, before starting the
download session:
mkdir -v $LFS/sources
Make this directory writable and sticky. “Sticky” means that even if multiple users have write permission on a directory, only the owner of a file can delete the file within a sticky directory. The following command will enable the write and sticky modes:
chmod -v a+wt $LFS/sources
Download or otherwise obtain the following packages:
Home page: http://www.gnu.org/software/autoconf/
Download: http://ftp.gnu.org/gnu/autoconf/autoconf-2.61.tar.bz2
MD5 sum: 36d3fe706ad0950f1be10c46a429efe0
Home page: http://www.gnu.org/software/automake/
Download: http://ftp.gnu.org/gnu/automake/automake-1.10.tar.bz2
MD5 sum: 0e2e0f757f9e1e89b66033905860fded
Home page: http://www.gnu.org/software/bash/
Download: http://ftp.gnu.org/gnu/bash/bash-3.2.tar.gz
MD5 sum: 00bfa16d58e034e3c2aa27f390390d30
Download: http://ftp.gnu.org/gnu/bash/bash-doc-3.2.tar.gz
MD5 sum: 0e904cb46ca873fcfa65df19b024bec9
Home page: http://www.oracle.com/technology/software/products/berkeley-db/index.html
Download: http://download-east.oracle.com/berkeley-db/db-4.5.20.tar.gz
MD5 sum: b0f1c777708cb8e9d37fb47e7ed3312d
Home page: http://sources.redhat.com/binutils/
Download: http://ftp.gnu.org/gnu/binutils/binutils-2.17.tar.bz2
MD5 sum: e26e2e06b6e4bf3acf1dc8688a94c0d1
Home page: http://www.gnu.org/software/bison/
Download: http://ftp.gnu.org/gnu/bison/bison-2.3.tar.bz2
MD5 sum: c18640c6ec31a169d351e3117ecce3ec
Home page: http://www.bzip.org/
Download: http://www.bzip.org/1.0.4/bzip2-1.0.4.tar.gz
MD5 sum: fc310b254f6ba5fbb5da018f04533688
Home page: http://www.gnu.org/software/coreutils/
Download: http://ftp.gnu.org/gnu/coreutils/coreutils-6.9.tar.bz2
MD5 sum: c9607d8495f16e98906e7ed2d9751a06
Home page: http://www.gnu.org/software/dejagnu/
Download: http://ftp.gnu.org/gnu/dejagnu/dejagnu-1.4.4.tar.gz
MD5 sum: 053f18fd5d00873de365413cab17a666
Home page: http://www.gnu.org/software/diffutils/
Download: http://ftp.gnu.org/gnu/diffutils/diffutils-2.8.1.tar.gz
MD5 sum: 71f9c5ae19b60608f6c7f162da86a428
Home page: http://e2fsprogs.sourceforge.net/
Download: http://prdownloads.sourceforge.net/e2fsprogs/e2fsprogs-1.40.2.tar.gz
MD5 sum: 130ce559a0f311ea2bc04a47b4982d0a
Home page: http://expect.nist.gov/
Download: http://expect.nist.gov/src/expect-5.43.0.tar.gz
MD5 sum: 43e1dc0e0bc9492cf2e1a6f59f276bc3
Download: ftp://ftp.gw.com/mirrors/pub/unix/file/file-4.21.tar.gz
MD5 sum: 9e3503116f4269a1be70220ee2234b0e
File (4.21) may no longer be available at the listed location. The site administrators of the master download location occasionally remove older versions when new ones are released. An alternative download location that may have the correct version available can also be found at: http://www.linuxfromscratch.org/lfs/download.html#ftp.
Home page: http://www.gnu.org/software/findutils/
Download: http://ftp.gnu.org/gnu/findutils/findutils-4.2.31.tar.gz
MD5 sum: a0e31a0f18a49709bf5a449867c8049a
Home page: http://flex.sourceforge.net
Download: http://prdownloads.sourceforge.net/flex/flex-2.5.33.tar.bz2
MD5 sum: 343374a00b38d9e39d1158b71af37150
Home page: http://www.gnu.org/software/gawk/
Download: http://ftp.gnu.org/gnu/gawk/gawk-3.1.5.tar.bz2
MD5 sum: 5703f72d0eea1d463f735aad8222655f
Home page: http://gcc.gnu.org/
Download: http://ftp.gnu.org/gnu/gcc/gcc-4.1.2/gcc-4.1.2.tar.bz2
MD5 sum: a4a3eb15c96030906d8494959eeda23c
Home page: http://www.gnu.org/software/gettext/
Download: http://ftp.gnu.org/gnu/gettext/gettext-0.16.1.tar.gz
MD5 sum: 3d9ad24301c6d6b17ec30704a13fe127
Home page: http://www.gnu.org/software/libc/
Download: http://ftp.gnu.org/gnu/glibc/glibc-2.5.1.tar.bz2
MD5 sum: 10ea72e2c4d56c6aa13dabb7c4f9b195
Download: http://ftp.gnu.org/gnu/glibc/glibc-libidn-2.5.1.tar.gz
MD5 sum: 51b46f055908a5f8e409c4200d828093
Home page: http://www.gnu.org/software/grep/
Download: http://ftp.gnu.org/gnu/grep/grep-2.5.1a.tar.bz2
MD5 sum: 52202fe462770fa6be1bb667bd6cf30c
Home page: http://www.gnu.org/software/groff/
Download: http://ftp.gnu.org/gnu/groff/groff-1.18.1.4.tar.gz
MD5 sum: ceecb81533936d251ed015f40e5f7287
Home page: http://www.gnu.org/software/grub/
Download: ftp://alpha.gnu.org/gnu/grub/grub-0.97.tar.gz
MD5 sum: cd3f3eb54446be6003156158d51f4884
Home page: http://www.gzip.org/
Download: http://ftp.gnu.org/gnu/gzip/gzip-1.3.12.tar.gz
MD5 sum: b5bac2d21840ae077e0217bc5e4845b1
Home page: http://www.sethwklein.net/projects/iana-etc/
Download: http://www.sethwklein.net/projects/iana-etc/downloads/iana-etc-2.20.tar.bz2
MD5 sum: 51d584b7b6115528c21e8ea32250f2b1
Home page: http://www.gnu.org/software/inetutils/
Download: http://ftp.gnu.org/gnu/inetutils/inetutils-1.5.tar.gz
MD5 sum: aeacd11d19bf25c89d4eff38346bdfb9
Home page: http://linux-net.osdl.org/index.php/Iproute2
Download: http://developer.osdl.org/dev/iproute2/download/iproute2-2.6.20-070313.tar.gz
MD5 sum: 7bc5883aadf740761fa2dd70b661e8cc
Download: http://www.kernel.org/pub/linux/utils/kbd/kbd-1.12.tar.bz2
MD5 sum: 069d1175b4891343b107a8ac2b4a39f6
Home page: http://www.greenwoodsoftware.com/less/
Download: http://www.greenwoodsoftware.com/less/less-406.tar.gz
MD5 sum: c6062663b5be92dfcdfd6300ba0811e4
Download: http://www.linuxfromscratch.org/lfs/downloads/6.3-branch/lfs-bootscripts-20070730.tar.bz2
MD5 sum: d50c72aa2f45c646f384a1ffeb20fafe
Home page: http://www.gnu.org/software/libtool/
Download: http://ftp.gnu.org/gnu/libtool/libtool-1.5.24.tar.gz
MD5 sum: d0071c890101fcf4f2be8934a37841b0
Home page: http://www.kernel.org/
Download: http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.22.1.tar.bz2
MD5 sum: 50249e822a2a112d9221129a4a3af374
The Linux kernel is updated relatively often, many times due to discoveries of security vulnerabilities. The latest available 2.6.22.x kernel version should be used, unless the errata page says otherwise.
Home page: http://www.gnu.org/software/m4/
Download: http://ftp.gnu.org/gnu/m4/m4-1.4.10.tar.bz2
MD5 sum: 0a35bab2f5d605e08083d7e3cbd4b8b0
Home page: http://www.gnu.org/software/make/
Download: http://ftp.gnu.org/gnu/make/make-3.81.tar.bz2
MD5 sum: 354853e0b2da90c527e35aabb8d6f1e6
Home page: http://www.nongnu.org/man-db/
Download: http://savannah.nongnu.org/download/man-db/man-db-2.4.4.tar.gz
MD5 sum: 9d7952de1aeb9121497a8204c59c56d7
Download: http://www.kernel.org/pub/linux/docs/manpages/Archive/man-pages-2.63.tar.bz2
MD5 sum: aeddbf93dbb0aeac1c8ad950e80aad54
Home page: http://www.mktemp.org/
Download: ftp://ftp.mktemp.org/pub/mktemp/mktemp-1.5.tar.gz
MD5 sum: 9a35c59502a228c6ce2be025fc6e3ff2
Home page: http://www.kerneltools.org/
Download: http://www.kerneltools.org/pub/downloads/module-init-tools/module-init-tools-3.2.2.tar.bz2
MD5 sum: a1ad0a09d3231673f70d631f3f5040e9
Home page: http://dickey.his.com/ncurses/
Download: ftp://invisible-island.net/ncurses/ncurses-5.6.tar.gz
MD5 sum: b6593abe1089d6aab1551c105c9300e3
Home page: http://www.gnu.org/software/patch/
Download: http://ftp.gnu.org/gnu/patch/patch-2.5.4.tar.gz
MD5 sum: ee5ae84d115f051d87fcaaef3b4ae782
Home page: http://www.perl.com/
Download: http://ftp.funet.fi/pub/CPAN/src/perl-5.8.8.tar.bz2
MD5 sum: a377c0c67ab43fd96eeec29ce19e8382
Home page: http://procps.sourceforge.net/
Download: http://procps.sourceforge.net/procps-3.2.7.tar.gz
MD5 sum: f490bca772b16472962c7b9f23b1e97d
Home page: http://psmisc.sourceforge.net/
Download: http://prdownloads.sourceforge.net/psmisc/psmisc-22.5.tar.gz
MD5 sum: 09c20fd899c2c1bd2dce02a510f99fab
Home page: http://cnswww.cns.cwru.edu/php/chet/readline/rltop.html
Download: http://ftp.gnu.org/gnu/readline/readline-5.2.tar.gz
MD5 sum: e39331f32ad14009b9ff49cc10c5e751
Home page: http://www.gnu.org/software/sed/
Download: http://ftp.gnu.org/gnu/sed/sed-4.1.5.tar.gz
MD5 sum: 7a1cbbbb3341287308e140bd4834c3ba
Download: ftp://ftp.pld.org.pl/software/shadow/shadow-4.0.18.1.tar.bz2
MD5 sum: e7751d46ecf219c07ae0b028ab3335c6
Shadow (4.0.18.1) may no longer be available at the listed location. The site administrators of the master download location move older versions to ftp://ftp.pld.org.pl/software/shadow/old/ when new ones are released.
Home page: http://www.infodrom.org/projects/sysklogd/
Download: http://www.infodrom.org/projects/sysklogd/download/sysklogd-1.4.1.tar.gz
MD5 sum: d214aa40beabf7bdb0c9b3c64432c774
Download: ftp://ftp.cistron.nl/pub/people/miquels/sysvinit/sysvinit-2.86.tar.gz
MD5 sum: 7d5d61c026122ab791ac04c8a84db967
Home page: http://www.gnu.org/software/tar/
Download: http://ftp.gnu.org/gnu/tar/tar-1.18.tar.bz2
MD5 sum: 70170208d7c1bb9ab40120579434b6a3
Home page: http://tcl.sourceforge.net/
Download: http://prdownloads.sourceforge.net/tcl/tcl8.4.15-src.tar.gz
MD5 sum: 5e1b71eef1f75a294072aa3218f62b66
Home page: http://www.gnu.org/software/texinfo/
Download: http://ftp.gnu.org/gnu/texinfo/texinfo-4.9.tar.bz2
MD5 sum: f4458e4b81e5469fa0815c35654141ab
Home page: http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html
Download: http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-113.tar.bz2
MD5 sum: cb9a227206b9d85ae8cfc88fc51c1710
Download: http://www.linuxfromscratch.org/lfs/downloads/6.3-branch/udev-config-20070731.tar.bz2
MD5 sum: 49c72e712f38c18884bd11a9a3b7e968
Download: http://www.kernel.org/pub/linux/utils/util-linux/util-linux-2.12r.tar.bz2
MD5 sum: af9d9e03038481fbf79ea3ac33f116f9
Home page: http://www.vim.org
Download: ftp://ftp.vim.org/pub/vim/unix/vim-7.1.tar.bz2
MD5 sum: 44c6b4914f38d6f9aa959640b89da329
Home page: http://www.vim.org
Download: ftp://ftp.vim.org/pub/vim/extra/vim-7.1-lang.tar.gz
MD5 sum: 144aa049ba70621acf4247f0459f3ee7
Home page: http://www.zlib.net/
Download: http://www.zlib.net/zlib-1.2.3.tar.gz
MD5 sum: debc62758716a169df9f62e6ab2bc634
Total size of these packages: about 197 MB
In addition to the packages, several patches are also required. These patches correct any mistakes in the packages that should be fixed by the maintainer. The patches also make small modifications to make the packages easier to work with. The following patches will be needed to build an LFS system:
Download: http://www.linuxfromscratch.org/patches/lfs/6.3-branch/bash-3.2-fixes-5.patch
MD5 sum: 70e2c3983575a8e82f8601a417e126f0
Download: http://www.linuxfromscratch.org/patches/lfs/6.3-branch/bzip2-1.0.4-install_docs-1.patch
MD5 sum: 6a5ac7e89b791aae556de0f745916f7f
Download: http://www.linuxfromscratch.org/patches/lfs/6.3-branch/coreutils-6.9-i18n-1.patch
MD5 sum: 806ce5bcb16a763a77bea411ec5ff637
Download: http://www.linuxfromscratch.org/patches/lfs/6.3-branch/coreutils-6.9-suppress_uptime_kill_su-1.patch
MD5 sum: e8ae92cdec364ca2a318f5c4c77bf032
Download: http://www.linuxfromscratch.org/patches/lfs/6.3-branch/coreutils-6.9-uname-1.patch
MD5 sum: c05b735710fbd62239588c07084852a0
Download: http://www.linuxfromscratch.org/patches/lfs/6.3-branch/db-4.5.20-fixes-1.patch
MD5 sum: 4d6a476c9ccd1bb9fba9de0b5229f0da
Download: http://www.linuxfromscratch.org/patches/lfs/6.3-branch/diffutils-2.8.1-i18n-1.patch
MD5 sum: c8d481223db274a33b121fb8c25af9f7
Download: http://www.linuxfromscratch.org/patches/lfs/6.3-branch/expect-5.43.0-spawn-1.patch
MD5 sum: ef6d0d0221c571fb420afb7033b3bbba
Download: http://www.linuxfromscratch.org/patches/lfs/6.3-branch/gawk-3.1.5-segfault_fix-1.patch
MD5 sum: 7679530d88bf3eb56c42eb6aba342ddb
Download: http://www.linuxfromscratch.org/patches/lfs/6.3-branch/gcc-4.1.2-specs-1.patch
MD5 sum: a17be8ccfb978e73f382be5093dd8abd
Download: http://www.linuxfromscratch.org/patches/lfs/6.3-branch/grep-2.5.1a-redhat_fixes-2.patch
MD5 sum: 2c67910be2d0a54714f63ce350e6d8a6
Download: http://www.linuxfromscratch.org/patches/lfs/6.3-branch/groff-1.18.1.4-debian_fixes-1.patch
MD5 sum: 05607e7fcfd6e5091f020bf44ddca10b
Download: http://www.linuxfromscratch.org/patches/lfs/6.3-branch/grub-0.97-disk_geometry-1.patch
MD5 sum: bf1594e82940e25d089feca74c6f1879
Download: http://www.linuxfromscratch.org/patches/lfs/6.3-branch/inetutils-1.5-no_server_man_pages-2.patch
MD5 sum: ec83aa00fb111f6f9d9aca04de9cb753
Download: http://www.linuxfromscratch.org/patches/lfs/6.3-branch/kbd-1.12-backspace-1.patch
MD5 sum: 692c88bb76906d99cc20446fadfb6499
Download: http://www.linuxfromscratch.org/patches/lfs/6.3-branch/kbd-1.12-gcc4_fixes-1.patch
MD5 sum: 615bc1e381ab646f04d8045751ed1f69
Download: http://www.linuxfromscratch.org/patches/lfs/6.3-branch/mktemp-1.5-add_tempfile-3.patch
MD5 sum: 65d73faabe3f637ad79853b460d30a19
Download: http://www.linuxfromscratch.org/patches/lfs/6.3-branch/module-init-tools-3.2.2-modprobe-1.patch
MD5 sum: f1e452fdf3b8d7ef60148125e390c3e8
Download: http://www.linuxfromscratch.org/patches/lfs/6.3-branch/ncurses-5.6-coverity_fixes-1.patch
MD5 sum: aa2fa9d0e89bbfdb4ce7e0e6b4b46670
Download: http://www.linuxfromscratch.org/patches/lfs/6.3-branch/perl-5.8.8-libc-2.patch
MD5 sum: 3bf8aef1fb6eb6110405e699e4141f99
Download: http://www.linuxfromscratch.org/patches/lfs/6.3-branch/readline-5.2-fixes-3.patch
MD5 sum: dfa4b750f226cf9ea034ec753a78a742
Download: http://www.linuxfromscratch.org/patches/lfs/6.3-branch/shadow-4.0.18.1-useradd_fix-2.patch
MD5 sum: 5f35528f38d5432d5fa2dd79d04bdfdd
Download: http://www.linuxfromscratch.org/patches/lfs/6.3-branch/sysklogd-1.4.1-8bit-1.patch
MD5 sum: cc0d9c3bd67a6b6357e42807cf06073e
Download: http://www.linuxfromscratch.org/patches/lfs/6.3-branch/sysklogd-1.4.1-fixes-2.patch
MD5 sum: ed5b25ca9a4eeb4f4f82b300a27b1ef4
Download: http://www.linuxfromscratch.org/patches/lfs/6.3-branch/texinfo-4.9-multibyte-1.patch
MD5 sum: 6cb5b760cfdd2dd53a0430eb572a8aaa
Download: http://www.linuxfromscratch.org/patches/lfs/6.3-branch/texinfo-4.9-tempfile_fix-1.patch
MD5 sum: 559bda136a2ac7777ecb67511227af85
Download: http://www.linuxfromscratch.org/patches/lfs/6.3-branch/util-linux-2.12r-cramfs-1.patch
MD5 sum: 1c3f40b30e12738eb7b66a35b7374572
Download: http://www.linuxfromscratch.org/patches/lfs/6.3-branch/util-linux-2.12r-lseek-1.patch
MD5 sum: 5d6c86321c1ea74d7ed7cf57861da423
Download: http://www.linuxfromscratch.org/patches/lfs/6.3-branch/vim-7.1-fixes-1.patch
MD5 sum: 744bc215560d3fbe80bfef4bab270f9a
Download: http://www.linuxfromscratch.org/patches/lfs/6.3-branch/vim-7.1-mandir-1.patch
MD5 sum: b6426eb4192faba1e867ddd502323f5b
Total size of these patches: about 780.9 KB
In addition to the above required patches, there exist a number of optional patches created by the LFS community. These optional patches solve minor problems or enable functionality that is not enabled by default. Feel free to peruse the patches database located at http://www.linuxfromscratch.org/patches/ and acquire any additional patches to suit the system needs.
Throughout this book, the environment variable LFS will be used several times. It is paramount
that this variable is always defined. It should be set to the
mount point chosen for the LFS partition. Check that the
LFS variable is set up properly
with:
echo $LFS
Make sure the output shows the path to the LFS partition's
mount point, which is /mnt/lfs if
the provided example was followed. If the output is incorrect,
the variable can be set with:
export LFS=/mnt/lfs
Having this variable set is beneficial in that commands such as mkdir $LFS/tools can be typed literally. The shell will automatically replace “$LFS” with “/mnt/lfs” (or whatever the variable was set to) when it processes the command line.
Do not forget to check that $LFS is
set whenever you leave and reenter the current working
environment (as when doing a su to root or another user).
All programs compiled in Chapter
5 will be installed under $LFS/tools to keep them separate from the
programs compiled in Chapter
6. The programs compiled here are temporary tools and will
not be a part of the final LFS system. By keeping these
programs in a separate directory, they can easily be discarded
later after their use. This also prevents these programs from
ending up in the host production directories (easy to do by
accident in Chapter
5).
Create the required directory by running the following as
root:
mkdir -v $LFS/tools
The next step is to create a /tools symlink on the host system. This will
point to the newly-created directory on the LFS partition. Run
this command as root as well:
ln -sv $LFS/tools /
The above command is correct. The ln command has a few
syntactic variations, so be sure to check info coreutils ln and
ln(1) before reporting what you
may think is an error.
The created symlink enables the toolchain to be compiled 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).
When logged in as user root,
making a single mistake can damage or destroy a system.
Therefore, we recommend building the packages in this chapter
as an unprivileged user. You could use your own user name, but
to make it easier to set up a clean working environment, create
a new user called lfs as a
member of a new group (also named lfs) and use this user during the
installation process. As root,
issue the following commands to add the new user:
groupadd lfs useradd -s /bin/bash -g lfs -m -k /dev/null lfs
The meaning of the command line options:
-s
/bin/bash
This makes bash the default shell
for user lfs.
-g
lfs
This option adds user lfs
to group lfs.
-m
This creates a home directory for lfs.
-k
/dev/null
This parameter prevents possible copying of files from a
skeleton directory (default is /etc/skel) by changing the input
location to the special null device.
lfs
This is the actual name for the created group and user.
To log in as lfs (as opposed to
switching to user lfs when
logged in as root, which does
not require the lfs user to
have a password), give lfs a
password:
passwd lfs
Grant lfs full access to
$LFS/tools by making lfs the directory owner:
chown -v lfs $LFS/tools
If a separate working directory was created as suggested, give
user lfs ownership of this
directory:
chown -v 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
login shell as opposed to a non-login shell. The difference
between these two types of shells can be found in detail in
bash(1) and info bash.
Set up a good working environment by creating two new startup
files for the bash shell. While logged in
as user lfs, issue the
following command to create a new .bash_profile:
cat > ~/.bash_profile << "EOF"
exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash
EOF
When logged on as user lfs, the
initial shell is usually a login shell which reads the
/etc/profile of the host
(probably containing some settings and environment variables)
and then .bash_profile. The
exec env
-i.../bin/bash command in the .bash_profile file replaces the running shell
with a new one with a completely empty environment, except for
the HOME, TERM, and PS1
variables. This ensures that no unwanted and potentially
hazardous environment variables from the host system leak into
the build environment. The technique used here achieves the
goal of ensuring a clean environment.
The new instance of the shell is a non-login shell, which does not read
the /etc/profile or .bash_profile files, but rather reads the
.bashrc file instead. Create the
.bashrc file now:
cat > ~/.bashrc << "EOF"
set +h
umask 022
LFS=/mnt/lfs
LC_ALL=POSIX
PATH=/tools/bin:/bin:/usr/bin
export LFS LC_ALL PATH
EOF
The set +h
command turns off bash's hash function. Hashing
is ordinarily a useful feature—bash uses a hash table to
remember the full path of executable files to avoid searching
the PATH time and again to find the
same executable. However, the new tools should be used as soon
as they are installed. By switching off the hash function, the
shell will always search the PATH
when a program is to be run. As such, the shell will find the
newly compiled tools in $LFS/tools as soon as they are available
without remembering a previous version of the same program in a
different location.
Setting the user file-creation mask (umask) to 022 ensures that
newly created files and directories are only writable by their
owner, but are readable and executable by anyone (assuming
default modes are used by the open(2) system call, new files will end up
with permission mode 644 and directories with mode 755).
The LFS variable should be set to
the chosen mount point.
The LC_ALL variable controls the
localization of certain programs, making their messages follow
the conventions of a specified country. If the 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 issues if you exit the chroot environment
and wish to return later. Setting LC_ALL to “POSIX” or “C” (the two are equivalent) ensures that
everything will work as expected in the chroot environment.
By putting /tools/bin ahead of
the standard PATH, all the programs
installed in Chapter
5 are picked up by the shell immediately after their
installation. This, combined with turning off hashing, limits
the risk that old programs are used from the host when the same
programs are available in the chapter 5 environment.
Finally, to have the environment fully prepared for building the temporary tools, source the just-created user profile:
source ~/.bash_profile
Many people would like to know beforehand approximately how long it takes to compile and install each package. Because Linux From Scratch can be built on many different systems, it is impossible to provide accurate time estimates. The biggest package (Glibc) will take approximately 20 minutes on the fastest systems, but could take up to three days on slower systems! Instead of providing actual times, the Standard Build Unit (SBU) measure will be used instead.
The SBU measure works as follows. The first package to be compiled from this book is Binutils in Chapter 5. The time it takes to compile this package is what will be referred to as the Standard Build Unit or SBU. All other compile times will be expressed relative to this time.
For example, consider a package whose compilation time is 4.5 SBUs. This means that if a system took 10 minutes to compile and install the first pass of Binutils, it will take approximately 45 minutes to build this example package. Fortunately, most build times are shorter than the one for Binutils.
In general, SBUs are not entirely accurate because they depend on many factors, including the host system's version of GCC. Note that on Symmetric Multi-Processor (SMP)-based machines, SBUs are even less accurate. They are provided here to give an estimate of how long it might take to install a package, but the numbers can vary by as much as dozens of minutes in some cases.
To view actual timings for a number of specific machines, we recommend The LinuxFromScratch SBU Home Page at http://www.linuxfromscratch.org/~sbu/.
Most packages provide a test suite. Running the test suite for a newly built package is a good idea because it can provide a “sanity check” indicating that everything compiled correctly. A test suite that passes its set of checks usually proves that the package is functioning as the developer intended. It does not, however, guarantee that the package is totally bug free.
Some test suites are more important than others. For example, the test suites for the core toolchain packages—GCC, Binutils, and Glibc—are of the utmost importance due to their central role in a properly functioning system. The test suites for GCC and Glibc can take a very long time to complete, especially on slower hardware, but are strongly recommended.
Experience has shown that there is little to be gained from running the test suites in Chapter 5. There can be no escaping the fact that the host system always exerts some influence on the tests in that chapter, often causing inexplicable failures. Because the tools built in Chapter 5 are temporary and eventually discarded, we do not recommend running the test suites in Chapter 5 for the average reader. The instructions for running those test suites are provided for the benefit of testers and developers, but they are strictly optional.
A common issue with running the test suites for Binutils and
GCC is running out of pseudo terminals (PTYs). This can result
in a high number of failing tests. This may happen for several
reasons, but the most likely cause is that the host system does
not have the devpts file system
set up correctly. This issue is discussed in greater detail in
Chapter
5.
Sometimes package test suites will fail, but for reasons which the developers are aware of and have deemed non-critical. Consult the logs located at http://www.linuxfromscratch.org/lfs/build-logs/6.3-branch/ to verify whether or not these failures are expected. This site is valid for all tests throughout this book.
This chapter shows how to compile and install a minimal Linux system. This system will contain just enough tools to start constructing the final LFS system in Chapter 6 and allow a working environment with more user convenience than a minimum environment would.
There are two steps in building this minimal system. The first step is to build a new and host-independent toolchain (compiler, assembler, linker, libraries, and a few useful utilities). The second step uses this toolchain to build the other essential tools.
The files compiled in this chapter will be installed under the
$LFS/tools directory to keep them
separate from the files installed in the next chapter and the
host production directories. Since the packages compiled here
are temporary, we do not want them to pollute the soon-to-be
LFS system.
Before issuing the build instructions for a package, the
package should be unpacked as user lfs, and a cd into the created
directory should be performed. The build instructions assume
that the bash
shell is in use.
Several of the packages are patched before compilation, but only when the patch is needed to circumvent a problem. A patch is often needed in both this and the next chapter, but sometimes in only one or the other. Therefore, do not be concerned if instructions for a downloaded patch seem to be missing. Warning messages about offset or fuzz may also be encountered when applying a patch. Do not worry about these warnings, as the patch was still successfully applied.
During the compilation of most packages, there will be several warnings that scroll by on the screen. These are normal and can safely be ignored. These warnings are as they appear—warnings about deprecated, but not invalid, use of the C or C++ syntax. C standards change fairly often, and some packages still use the older standard. This is not a problem, but does prompt the warning.
After installing each package, delete its source and build directories, unless specifically instructed otherwise. Deleting the sources prevents mis-configuration when the same package is reinstalled later.
Check one last time that the LFS
environment variable is set up properly:
echo $LFS
Make sure the output shows the path to the LFS partition's
mount point, which is /mnt/lfs,
using our example.
This section explains some of the rationale and technical details behind the overall build method. It is not essential to immediately understand everything in this section. Most of this information will be clearer after performing an actual build. This section can be referred back to at any time during the process.
The overall goal of Chapter 5 is to provide a temporary environment that can be chrooted into and from which can be produced a clean, trouble-free build of the target LFS system in Chapter 6. Along the way, we separate the new system from the host system as much as possible, and in doing so, build a self-contained and self-hosted toolchain. It should be noted that the build process has been designed to minimize the risks for new readers and provide maximum educational value at the same time.
Before continuing, be aware of the name of the working
platform, often referred to as the target triplet. Many
times, the target triplet will probably be i686-pc-linux-gnu. A simple way to
determine the name of the 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.
Also be aware of the name of the platform's dynamic linker,
often referred to as the dynamic loader (not to be confused
with the standard linker ld that is part of
Binutils). The dynamic linker provided by Glibc finds and
loads the shared libraries needed by a program, prepares the
program to run, and then runs it. The name of the dynamic
linker will usually be ld-linux.so.2. On platforms that are less
prevalent, the name might be ld.so.1, and newer 64 bit platforms might
be named something else entirely. The name of the platform's
dynamic linker can be determined by looking in the
/lib directory on the host
system. A sure-fire way to determine the name is to inspect a
random binary from the host system by running: readelf -l <name of binary> | 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:
The process is similar in principle to cross-compiling, whereby tools installed in the same prefix work in cooperation, and thus utilize a little GNU “magic”
Careful manipulation of the standard linker's library search path ensures programs are linked only against chosen libraries
Careful manipulation of gcc's specs file tells the compiler which
target dynamic linker will be used
Binutils is installed first because the configure runs of both GCC and Glibc perform various feature tests on the assembler and linker 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 an entire distribution. A test suite failure will usually highlight this error before too much additional work is performed.
Binutils installs its assembler and linker in two locations,
/tools/bin and /tools/$TARGET_TRIPLET/bin. 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, an ld --verbose | grep
SEARCH will illustrate the current search paths
and their order. It shows which files are linked by
ld by compiling a
dummy program and passing the --verbose switch to the linker.
For example, gcc dummy.c
-Wl,--verbose 2>&1 | grep succeeded will
show all the files successfully opened during the linking.
The next package installed is GCC. An example of what can be seen during its run of configure is:
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. To find out which standard
linker gcc will
use, run: gcc
-print-prog-name=ld.
Detailed information can be obtained from gcc by passing it the
-v command line option
while compiling a dummy program. For example, gcc -v dummy.c will show
detailed information about the preprocessor, compilation, and
assembly stages, including gcc's included 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 not an
issue since Glibc will always use the gcc found in a PATH directory. The binary tools and kernel
headers can be a bit more complicated. Therefore, take no risks
and use the available configure switches to enforce the correct
selections. After the run of configure, check the contents
of the config.make file in the
glibc-build directory for all
important details. Note the use of CC="gcc -B/tools/bin/" to control
which binary tools are used and the use of the -nostdinc and -isystem flags to control the
compiler's include search path. These items 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, make some adjustments to ensure
that searching and linking take place only within the
/tools prefix. Install an
adjusted ld,
which has a hard-wired search path limited to /tools/lib. Then amend gcc's specs file to point to
the 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 Executable and Link
Format (ELF)-shared executable. This can be inspected by
running: readelf -l <name of
binary> | grep interpreter. Amending gcc's
specs file ensures that every program compiled from here
through the end of this chapter will use the new dynamic linker
in /tools/lib.
The need to use the new dynamic linker is also the reason why
the Specs patch is applied 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 the 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.
Upon entering the chroot environment in Chapter
6, the first major package to be installed is Glibc, due to
its self-sufficient nature mentioned above. Once this Glibc is
installed into /usr, perform a
quick changeover of the toolchain defaults, then proceed in
building the rest of the target LFS system.
The Binutils package contains a linker, an assembler, and other tools for handling object files.
It is important that Binutils be the first package compiled because both Glibc and GCC perform various tests on the available linker and assembler to determine which of their own features to enable.
The Binutils documentation recommends building Binutils outside of the source directory in a dedicated build directory:
mkdir -v ../binutils-build cd ../binutils-build
In order for the SBU values listed in the rest of the book
to be of any use, measure the time it takes to build this
package from the configuration, up to and including the
first install. To achieve this easily, wrap the three
commands in a time command like this:
time { ./configure ...
&& make && make install; }.
Now prepare Binutils for compilation:
CC="gcc -B/usr/bin/" ../binutils-2.17/configure \
--prefix=/tools --disable-nls
The meaning of the configure options:
CC="gcc
-B/usr/bin/"
This forces gcc to prefer the
linker from the host in /usr/bin. This is necessary on some
hosts where the new ld built here is not
compatible with the host's gcc.
--prefix=/tools
This tells the configure script to prepare to install
the Binutils programs in the /tools directory.
--disable-nls
This disables internationalization as i18n is not needed for the temporary tools.
Continue with compiling the package:
make
Compilation is now complete. Ordinarily we would now run the test suite, but at this early stage the test suite framework (Tcl, Expect, and DejaGNU) is not yet in place. The benefits of running the tests at this point are minimal since the programs from this first pass will soon be replaced by those from the second.
Install the package:
make install
Next, prepare the linker for the “Adjusting” phase later on:
make -C ld clean make -C ld LIB_PATH=/tools/lib cp -v ld/ld-new /tools/bin
The meaning of the make parameters:
-C ld
clean
This tells the make program to remove all compiled
files in the ld
subdirectory.
-C ld
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 point it to the temporary tools location. The
value of this variable specifies the linker's default
library search path. This preparation is used later in
the chapter.
Details on this package are located in Section 6.11.2, “Contents of Binutils.”
The GCC package contains the GNU compiler collection, which includes the C and C++ compilers.
The GCC documentation recommends building GCC outside of the source directory in a dedicated build directory:
mkdir -v ../gcc-build cd ../gcc-build
Prepare GCC for compilation:
CC="gcc -B/usr/bin/" ../gcc-4.1.2/configure --prefix=/tools \
--with-local-prefix=/tools --disable-nls --enable-shared \
--enable-languages=c
The meaning of the configure options:
CC="gcc
-B/usr/bin/"
This forces gcc to prefer the
linker from the host in /usr/bin. This is necessary on some
hosts where the new ld built in the
previous section is not compatible with the host's
gcc.
--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, it
helps to minimize the influence of the host system.
--enable-shared
This switch allows the building of libgcc_s.so.1 and libgcc_eh.a. Having libgcc_eh.a available ensures that
the configure script for Glibc (the next package we
compile) produces the proper results.
--enable-languages=c
This option ensures that only the C compiler is built.
Continue with compiling the package:
make bootstrap
The meaning of the make parameter:
bootstrap
This target does not 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. This also implies that it was compiled correctly.
Compilation is now complete. At this point, the test suite would normally be run, but, as mentioned before, the test suite framework is not in place yet. The benefits of running the tests at this point are minimal since the programs from this first pass will soon be replaced.
Install the package:
make install
As a finishing touch, create a symlink. Many programs and scripts run cc instead of gcc, which is used to keep programs generic and therefore usable on all kinds of UNIX systems where the GNU C compiler is not always installed. Running cc leaves the system administrator free to decide which C compiler to install:
ln -vs gcc /tools/bin/cc
Details on this package are located in Section 6.12.2, “Contents of GCC.”
The Linux API Headers expose the kernel's API for use by Glibc.
The Linux kernel needs to expose an Application Programming Interface (API) for the system's C library (Glibc in LFS) to utilize. This is done by way of sanitizing various C header files that are shipped in the Linux kernel source tarball.
Install the header files:
make mrproper make headers_check make INSTALL_HDR_PATH=dest headers_install cp -rv dest/include/* /tools/include
Details on this package are located in Section 6.7.2, “Contents of Linux API Headers.”
The Glibc package contains the main C library. This library provides the basic routines for allocating memory, searching directories, opening and closing files, reading and writing files, string handling, pattern matching, arithmetic, and so on.
The Glibc documentation recommends building Glibc outside of the source directory in a dedicated build directory:
mkdir -v ../glibc-build cd ../glibc-build
Next, prepare Glibc for compilation:
../glibc-2.5.1/configure --prefix=/tools \
--disable-profile --enable-add-ons \
--enable-kernel=2.6.0 --with-binutils=/tools/bin \
--without-gd --with-headers=/tools/include \
--without-selinux
The meaning of the configure options:
--disable-profile
This builds the libraries without profiling information. Omit this option if profiling on the temporary tools is necessary.
--enable-add-ons
This tells Glibc to use the NPTL add-on as its threading library.
--enable-kernel=2.6.0
This tells Glibc to compile the library with support for 2.6.x Linux kernels.
--with-binutils=/tools/bin
While not required, this switch ensures that there are no errors pertaining to which Binutils programs get used during the Glibc build.
--without-gd
This prevents the build of the memusagestat program, which insists on linking against the host's libraries (libgd, libpng, libz, etc.).
--with-headers=/tools/include
This tells Glibc to compile itself against the headers recently installed to the tools directory, so that it knows exactly what features the kernel has and can optimize itself accordingly.
--without-selinux
When building from hosts that include SELinux functionality (e.g., Fedora Core 3), Glibc will build with support for SELinux. As the LFS tools environment does not contain support for SELinux, a Glibc compiled with such support will fail to operate correctly.
During this stage the following warning might appear:
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 can sometimes cause issues when running the test suite. This msgfmt program is part of the Gettext package which the host distribution should provide. If msgfmt is present but deemed incompatible, upgrade the host system's Gettext package or continue without it and see if the test suite runs without problems regardless.
Compile the package:
make
Compilation is now complete. As mentioned earlier, running the test suites for the temporary tools installed in this chapter is not mandatory. To run the Glibc test suite (if desired), the following command will do so:
make check
For a discussion of test failures that are of particular importance, please see Section 6.9, “Glibc-2.5.1.”
In this chapter, some tests can be adversely affected by existing tools or environmental issues on the host system. Glibc test suite failures in this chapter are typically not worrisome. The Glibc installed in Chapter 6 is the one that will ultimately end up being used, so that is the one that needs to pass most tests (even in Chapter 6, some failures could still occur, for example, with the math tests).
When experiencing a failure, make a note of it, then continue by reissuing the make check command. The test suite should pick up where it left off and continue. This stop-start sequence can be circumvented by issuing a make -k check command. If using this option, be sure to log the output so that the log file can be examined for failures later.
The install stage of Glibc will issue a harmless warning at
the end about the absence of /tools/etc/ld.so.conf. Prevent this warning
with:
mkdir -v /tools/etc touch /tools/etc/ld.so.conf
Install the package:
make install
Different countries and cultures have varying conventions for how to communicate. These conventions range from the format for representing dates and times to more complex issues, such as the language spoken. The “internationalization” of GNU programs works by locale.
If the test suites are not being run in this chapter (as per the recommendation), there is no need to install the locales now. The appropriate locales will be installed in the next chapter. To install the Glibc locales anyway, use instructions from Section 6.9, “Glibc-2.5.1.”
Details on this package are located in Section 6.9.4, “Contents of Glibc.”
Now that the temporary C libraries have been installed, all tools compiled in the rest of this chapter should be linked against these libraries. In order to accomplish this, the linker and the compiler's specs file need to be adjusted.
The linker, adjusted at the end of the first pass of Binutils,
needs to be renamed so that it can be properly found and used.
First, backup the original linker, then replace it with the
adjusted linker. We'll also create a link to its counterpart in
/tools/$(gcc -dumpmachine)/bin:
mv -v /tools/bin/{ld,ld-old}
mv -v /tools/$(gcc -dumpmachine)/bin/{ld,ld-old}
mv -v /tools/bin/{ld-new,ld}
ln -sv /tools/bin/ld /tools/$(gcc -dumpmachine)/bin/ld
From this point onwards, everything will link only against the
libraries in /tools/lib.
The next task is to point GCC to the new dynamic linker. This is done by dumping GCC's “specs” file to a location where GCC will look for it by default. A simple sed substitution then alters the dynamic linker that GCC will use.
For the sake of accuracy, it is recommended to use a copy-and-paste method when issuing the following command. Be sure to visually inspect the specs file and verify that all occurrences of “/lib/ld-linux.so.2” have been replaced with “/tools/lib/ld-linux.so.2”:
If working on a platform where the name of the dynamic linker
is something other than ld-linux.so.2, replace “ld-linux.so.2” with the name of the
platform's dynamic linker in the following commands. Refer to
Section 5.2,
“Toolchain Technical Notes,” if necessary.
gcc -dumpspecs | sed 's@^/lib/ld-linux.so.2@/tools&@g' \ > `dirname $(gcc -print-libgcc-file-name)`/specs
During the build process, GCC runs a script (fixincludes) that scans the system for header files that may need to be fixed (they might contain syntax errors, for example), and installs the fixed versions in a private include directory. There is a possibility that, as a result of this process, some header files from the host system have found their way into GCC's private include directory. As the rest of this chapter only requires the headers from GCC and Glibc, which have both been installed at this point, any “fixed” headers can safely be removed. This helps to avoid any host headers polluting the build environment. Run the following commands to remove the header files in GCC's private include directory (you may find it easier to copy and paste these commands, rather than typing them by hand, due to their length):
GCC_INCLUDEDIR=`dirname $(gcc -print-libgcc-file-name)`/include &&
find ${GCC_INCLUDEDIR}/* -maxdepth 0 -xtype d -exec rm -rvf '{}' \; &&
rm -vf `grep -l "DO NOT EDIT THIS FILE" ${GCC_INCLUDEDIR}/*` &&
unset GCC_INCLUDEDIR
At this point, it is imperative to stop and ensure that the basic functions (compiling and linking) of the new toolchain are working as expected. To perform a sanity check, run the following commands:
echo 'main(){}' > dummy.c
cc dummy.c
readelf -l a.out | grep ': /tools'
If everything is working correctly, there should be no errors, and the output of the last command will be of the form:
[Requesting program interpreter:
/tools/lib/ld-linux.so.2]
Note that /tools/lib appears as
the prefix of the dynamic linker.
If the output is not shown as above or there was no output at
all, then something is wrong. Investigate and retrace the
steps to find out where the problem is and correct it. This
issue must be resolved before continuing on. First, perform
the sanity check again, using gcc instead of cc. If this works, then the
/tools/bin/cc symlink is
missing. Revisit Section 5.4,
“GCC-4.1.2 - Pass 1,” and install the
symlink. Next, ensure that the PATH is correct. This can be checked by
running echo
$PATH and verifying that /tools/bin is at the head of the list. If
the PATH is wrong it could mean
that you are not logged in as user lfs or that something went wrong back in
Section 4.4,
“Setting Up the Environment.” Another option
is that something may have gone wrong with the specs file
amendment above. In this case, redo the specs file amendment,
being careful to copy-and-paste the commands.
Once all is well, clean up the test files:
rm -v dummy.c a.out
Building TCL in the next section will serve as an additional check that the toolchain has been built properly. If TCL fails to build, it is an indication that something has gone wrong with the Binutils, GCC, or Glibc installation, but not with TCL itself.
The Tcl package contains the Tool Command Language.
This package and the next two (Expect and DejaGNU) are installed to support running the test suites for GCC and Binutils. Installing three packages for testing purposes may seem excessive, but it is very reassuring, if not essential, to know that the most important tools are working properly. Even if the test suites are not run in this chapter (they are not mandatory), these packages are required to run the test suites in Chapter 6.
Prepare Tcl for compilation:
cd unix ./configure --prefix=/tools
Build the package:
make
To test the results, issue: TZ=UTC make test. The Tcl
test suite is known to experience failures under certain host
conditions that are not fully understood. Therefore, test
suite failures here are not surprising, and are not
considered critical. The TZ=UTC parameter sets the time
zone to Coordinated Universal Time (UTC), also known as
Greenwich Mean Time (GMT), but only for the duration of the
test suite run. This ensures that the clock tests are
exercised correctly. Details on the TZ environment variable are provided in
Chapter
7.
Install the package:
make install
Install Tcl's headers. The next package, Expect, requires them to build.
make install-private-headers
Now make a necessary symbolic link:
ln -sv tclsh8.4 /tools/bin/tclsh
The Expect package contains a program for carrying out scripted dialogues with other interactive programs.
First, fix a bug that can result in false failures during the GCC test suite run:
patch -Np1 -i ../expect-5.43.0-spawn-1.patch
Next, force Expect's configure script to use /bin/stty instead of a /usr/local/bin/stty it may find on the host
system. This will ensure that our testsuite tools remain sane
for the final builds of our toolchain:
cp configure{,.bak}
sed 's:/usr/local/bin:/bin:' configure.bak > configure
Now prepare Expect for compilation:
./configure --prefix=/tools --with-tcl=/tools/lib \ --with-tclinclude=/tools/include --with-x=no
The meaning of the configure options:
--with-tcl=/tools/lib
This ensures that the configure script finds the Tcl installation in the temporary tools location instead of possibly locating an existing one on the host system.
--with-tclinclude=/tools/include
This explicitly tells Expect where to find Tcl's internal headers. Using this option avoids conditions where configure fails because it cannot automatically discover the location of Tcl's headers.
--with-x=no
This tells the configure script not to search for Tk (the Tcl GUI component) or the X Window System libraries, both of which may reside on the host system but will not exist in the temporary environment.
Build the package:
make
To test the results, issue: make test. Note that the
Expect test suite is known to experience failures under
certain host conditions that are not within our control.
Therefore, test suite failures here are not surprising and
are not considered critical.
Install the package:
make SCRIPTS="" install
The meaning of the make parameter:
SCRIPTS=""
This prevents installation of the supplementary Expect scripts, which are not needed.
The DejaGNU package contains a framework for testing other programs.
Prepare DejaGNU for compilation:
./configure --prefix=/tools
Build and install the package:
make install
To test the results, issue: make check.
The GCC package contains the GNU compiler collection, which includes the C and C++ compilers.
The tools required to test GCC and Binutils—Tcl, Expect
and DejaGNU—are installed now. GCC and Binutils can now
be rebuilt, linking them against the new Glibc and testing
them properly (if running the test suites in this chapter).
Please note that these test suites are highly dependent on
properly functioning PTYs which are provided by the host.
PTYs are most commonly implemented via the devpts file system. Check to see if the
host system is set up correctly in this regard by performing
a quick test:
expect -c "spawn ls"
The response might be:
The system has no more ptys.
Ask your system administrator to create more.If the above message is received, the host does not have its PTYs set up properly. In this case, there is no point in running the test suites for GCC and Binutils until this issue is resolved. Please consult the LFS FAQ at http://www.linuxfromscratch.org//lfs/faq.html#no-ptys for more information on how to get PTYs working.
As previously explained in Section 5.7, “Adjusting the Toolchain”, under normal circumstances the GCC fixincludes script is run in order to fix potentially broken header files. As GCC-4.1.2 and Glibc-2.5.1 have already been installed at this point, and their respective header files are known to not require fixing, the fixincludes script is not required. As mentioned previously, the script may in fact pollute the build environment by installing fixed headers from the host system into GCC's private include directory. The running of the fixincludes script can be suppressed by issuing the following commands:
cp -v gcc/Makefile.in{,.orig}
sed 's@\./fixinc\.sh@-c true@' gcc/Makefile.in.orig > gcc/Makefile.in
The bootstrap build performed in Section 5.4,
“GCC-4.1.2 - Pass 1” built GCC with the
-fomit-frame-pointer compiler
flag. Non-bootstrap builds omit this flag by default, so
apply the following sed to use it in order to
ensure consistent compiler builds:
cp -v gcc/Makefile.in{,.tmp}
sed 's/^XCFLAGS =$/& -fomit-frame-pointer/' gcc/Makefile.in.tmp \
> gcc/Makefile.in
Apply the following patch to change the location of GCC's
default dynamic linker (typically ld-linux.so.2):
patch -Np1 -i ../gcc-4.1.2-specs-1.patch
The above patch also removes /usr/include from GCC's include search
path. Patching now rather than adjusting the specs file after
installation ensures that the new dynamic linker is used
during the actual build of GCC. That is, all of the binaries
created during the build will link against the new Glibc.
The above patch is critical in ensuring a successful overall build. Do not forget to apply it.
Create a separate build directory again:
mkdir -v ../gcc-build cd ../gcc-build
Before starting to build GCC, remember to unset any environment variables that override the default optimization flags.
Now prepare GCC for compilation:
../gcc-4.1.2/configure --prefix=/tools \
--with-local-prefix=/tools --enable-clocale=gnu \
--enable-shared --enable-threads=posix \
--enable-__cxa_atexit --enable-languages=c,c++ \
--disable-libstdcxx-pch
The meaning of the new configure options:
--enable-clocale=gnu
This option ensures the correct locale model is selected for the C++ libraries under all circumstances. If the configure script finds the de_DE locale installed, it will select the correct gnu locale model. However, if the de_DE locale is not installed, there is the risk of building Application Binary Interface (ABI)-incompatible C++ libraries because the incorrect generic locale model may be selected.
--enable-threads=posix
This enables C++ exception handling for multi-threaded code.
--enable-__cxa_atexit
This option allows use of __cxa_atexit, rather than
atexit, to register C++
destructors for local statics and global objects. This
option is essential for fully standards-compliant
handling of destructors. It also affects the C++ ABI,
and therefore results in C++ shared libraries and C++
programs that are interoperable with other Linux
distributions.
--enable-languages=c,c++
This option ensures that both the C and C++ compilers are built.
--disable-libstdcxx-pch
Do not build the pre-compiled header (PCH) for
libstdc++. It takes up a
lot of space, and we have no use for it.
Compile the package:
make
There is no need to use the bootstrap target now because
the compiler being used to compile this GCC was built from
the exact same version of the GCC sources used earlier.
Compilation is now complete. As previously mentioned, running the test suites for the temporary tools compiled in this chapter is not mandatory. To run the GCC test suite anyway, use the following command:
make -k check
The -k flag is used
to make the test suite run through to completion and not stop
at the first failure. The GCC test suite is very
comprehensive and is almost guaranteed to generate a few
failures.
For a discussion of test failures that are of particular importance, please see Section 6.12, “GCC-4.1.2.”
Install the package:
make install
At this point, it is imperative to stop and ensure that the basic functions (compiling and linking) of the new toolchain are working as expected. To perform a sanity check, run the following commands:
echo 'main(){}' > dummy.c
cc dummy.c
readelf -l a.out | grep ': /tools'
If everything is working correctly, there should be no errors, and the output of the last command will be of the form:
[Requesting program interpreter:
/tools/lib/ld-linux.so.2]
Note that /tools/lib appears
as the prefix of the dynamic linker.
If the output is not shown as above or there was no output
at all, then something is wrong. Investigate and retrace
the steps to find out where the problem is and correct it.
This issue must be resolved before continuing on. First,
perform the sanity check again, using gcc instead of
cc. If this
works, then the /tools/bin/cc
symlink is missing. Revisit Section 5.4,
“GCC-4.1.2 - Pass 1,” and install the
symlink. Next, ensure that the PATH is correct. This can be checked by
running echo
$PATH and verifying that /tools/bin is at the head of the list. If
the PATH is wrong it could mean
that you are not logged in as user lfs or that something went wrong back
in Section 4.4,
“Setting Up the Environment.” Another
option is that something may have gone wrong with the specs
file amendment above. In this case, redo the specs file
amendment, being careful to copy-and-paste the commands.
Once all is well, clean up the test files:
rm -v dummy.c a.out
Details on this package are located in Section 6.12.2, “Contents of GCC.”
The Binutils package contains a linker, an assembler, and other tools for handling object files.
Create a separate build directory again:
mkdir -v ../binutils-build cd ../binutils-build
Prepare Binutils for compilation:
../binutils-2.17/configure --prefix=/tools \
--disable-nls --with-lib-path=/tools/lib
The meaning of the new configure options:
--with-lib-path=/tools/lib
This tells the configure script to specify the library
search path during the compilation of Binutils,
resulting in /tools/lib
being passed to the linker. This prevents the linker
from searching through library directories on the host.
Compile the package:
make
Compilation is now complete. As discussed earlier, running the test suite is not mandatory for the temporary tools here in this chapter. To run the Binutils test suite anyway, issue the following command:
make check
Install the package:
make install
Now prepare the linker for the “Re-adjusting” phase in the next chapter:
make -C ld clean make -C ld LIB_PATH=/usr/lib:/lib cp -v ld/ld-new /tools/bin
Details on this package are located in Section 6.11.2, “Contents of Binutils.”
The Ncurses package contains libraries for terminal-independent handling of character screens.
Prepare Ncurses for compilation:
./configure --prefix=/tools --with-shared \
--without-debug --without-ada --enable-overwrite
The meaning of the configure options:
--without-ada
This ensures that Ncurses does not build support for the Ada compiler which may be present on the host but will not be available once we enter the chroot environment.
--enable-overwrite
This tells Ncurses to install its header files into
/tools/include, instead
of /tools/include/ncurses, to ensure
that other packages can find the Ncurses headers
successfully.
Compile the package:
make
This package does not come with a test suite.
Install the package:
make install
Details on this package are located in Section 6.20.2, “Contents of Ncurses.”
The Bash package contains the Bourne-Again SHell.
Apply fixes for several bugs discovered since the initial release of Bash-3.2:
patch -Np1 -i ../bash-3.2-fixes-5.patch
Prepare Bash for compilation:
./configure --prefix=/tools --without-bash-malloc
The meaning of the configure option:
--without-bash-malloc
This option turns off the use of Bash's memory
allocation (malloc)
function which is known to cause segmentation faults.
By turning this option off, Bash will use the
malloc functions from
Glibc which are more stable.
Compile the package:
make
To test the results, issue: make tests.
Install the package:
make install
Make a link for the programs that use sh for a shell:
ln -vs bash /tools/bin/sh
Details on this package are located in Section 6.28.2, “Contents of Bash.”
The Bzip2 package contains programs for compressing and decompressing files. Compressing text files with bzip2 yields a much better compression percentage than with the traditional gzip.
The Bzip2 package does not contain a configure script. Compile and test it with:
make
Install the package:
make PREFIX=/tools install
Details on this package are located in Section 6.29.2, “Contents of Bzip2.”
The Coreutils package contains utilities for showing and setting the basic system characteristics.
Prepare Coreutils for compilation:
./configure --prefix=/tools
Compile the package:
make
To test the results, issue: make RUN_EXPENSIVE_TESTS=yes
check. The RUN_EXPENSIVE_TESTS=yes
parameter tells the test suite to run several additional
tests that are considered relatively expensive (in terms of
CPU power and memory usage) on some platforms, but generally
are not a problem on Linux.
Install the package:
make install
The above command refuses to install su because it cannot install it setuid root
as a non-privileged user. By manually installing it with a
different name, we can use it for running tests in the final
system as a non-privileged user and we keep a possibly useful
su from our
host first place in our PATH. Install it with:
cp -v src/su /tools/bin/su-tools
Details on this package are located in Section 6.16.2, “Contents of Coreutils.”
The Diffutils package contains programs that show the differences between files or directories.
Prepare Diffutils for compilation:
./configure --prefix=/tools
Compile the package:
make
This package does not come with a test suite.
Install the package:
make install
Details on this package are located in Section 6.30.2, “Contents of Diffutils.”
The Findutils package contains programs to find files. These programs are provided to recursively search through a directory tree and to create, maintain, and search a database (often faster than the recursive find, but unreliable if the database has not been recently updated).
Prepare Findutils for compilation:
./configure --prefix=/tools
Compile the package:
make
To test the results, issue: make check.
Install the package:
make install
Details on this package are located in Section 6.32.2, “Contents of Findutils.”
The Gawk package contains programs for manipulating text files.
Prepare Gawk for compilation:
./configure --prefix=/tools
Due to a bug in the configure script, Gawk
fails to detect certain aspects of locale support in Glibc.
This bug leads to, e.g., Gettext testsuite failures. Work
around this issue by appending the missing macro definitions
to config.h:
cat >> config.h << "EOF"
#define HAVE_LANGINFO_CODESET 1
#define HAVE_LC_MESSAGES 1
EOF
Compile the package:
make
To test the results, issue: make check.
Install the package:
make install
Details on this package are located in Section 6.35.2, “Contents of Gawk.”
The Gettext package contains utilities for internationalization and localization. These allow programs to be compiled with NLS (Native Language Support), enabling them to output messages in the user's native language.
For our temporary set of tools, we only need to build and install one binary from Gettext.
Prepare Gettext for compilation:
cd gettext-tools ./configure --prefix=/tools --disable-shared
The meaning of the configure option:
--disable-shared
We do not need to install any of the shared Gettext libraries at this time, therefore there is no need to build them.
Compile the package:
make -C gnulib-lib make -C src msgfmt
As only one binary has been compiled, it is not possible to run the testsuite without compiling additional support libraries from the Gettext package. It is therefore not recommended to attempt to run the testsuite at this stage.
Install the msgfmt binary:
cp -v src/msgfmt /tools/bin
Details on this package are located in Section 6.36.2, “Contents of Gettext.”
The Grep package contains programs for searching through files.
Prepare Grep for compilation:
./configure --prefix=/tools \
--disable-perl-regexp
The meaning of the configure option:
--disable-perl-regexp
This ensures that the grep program does not get linked against a Perl Compatible Regular Expression (PCRE) library that may be present on the host but will not be available once we enter the chroot environment.
Compile the package:
make
To test the results, issue: make check.
Install the package:
make install
Details on this package are located in Section 6.37.2, “Contents of Grep.”
The Gzip package contains programs for compressing and decompressing files.
Prepare Gzip for compilation:
./configure --prefix=/tools
Compile the package:
make
To test the results, issue: make check.
Install the package:
make install
Details on this package are located in Section 6.39.2, “Contents of Gzip.”
The Make package contains a program for compiling packages.
Prepare Make for compilation:
./configure --prefix=/tools
Compile the package:
make
To test the results, issue: make check.
Install the package:
make install
Details on this package are located in Section 6.44.2, “Contents of Make.”
The Patch package contains a program for modifying or creating files by applying a “patch” file typically created by the diff program.
Prepare Patch for compilation:
./configure --prefix=/tools
Compile the package:
make
This package does not come with a test suite.
Install the package:
make install
Details on this package are located in Section 6.48.2, “Contents of Patch.”
The Perl package contains the Practical Extraction and Report Language.
First adapt some hard-wired paths to the C library by applying the following patch:
patch -Np1 -i ../perl-5.8.8-libc-2.patch
Prepare Perl for compilation (make sure to get the 'Data/Dumper Fcntl IO POSIX' part of the command correct—they are all letters):
./configure.gnu --prefix=/tools -Dstatic_ext='Data/Dumper Fcntl IO POSIX'
The meaning of the configure options:
-Dstatic_ext='Data/Dumper Fcntl IO
POSIX'
This tells Perl to build the minimum set of static extensions needed for installing and testing the Coreutils and Glibc packages in the next chapter.
Only a few of the utilities contained in this package need to be built:
make perl utilities
Although Perl comes with a test suite, it is not recommended to run it at this point. Only part of Perl was built and running make test now will cause the rest of Perl to be built as well, which is unnecessary at this point. The test suite can be run in the next chapter if desired.
Install these tools and their libraries:
cp -v perl pod/pod2man /tools/bin mkdir -pv /tools/lib/perl5/5.8.8 cp -Rv lib/* /tools/lib/perl5/5.8.8
Details on this package are located in Section 6.23.2, “Contents of Perl.”
The Sed package contains a stream editor.
Prepare Sed for compilation:
./configure --prefix=/tools
Compile the package:
make
To test the results, issue: make check.
Install the package:
make install
Details on this package are located in Section 6.14.2, “Contents of Sed.”
The Tar package contains an archiving program.
Prepare Tar for compilation:
./configure --prefix=/tools
Compile the package:
make
To test the results, issue: make check.
Install the package:
make install
Details on this package are located in Section 6.53.2, “Contents of Tar.”
The Texinfo package contains programs for reading, writing, and converting info pages.
Prepare Texinfo for compilation:
./configure --prefix=/tools
Compile the package:
make
To test the results, issue: make check.
Install the package:
make install
Details on this package are located in Section 6.54.2, “Contents of Texinfo.”
The Util-linux package contains miscellaneous utility programs. Among them are utilities for handling file systems, consoles, partitions, and messages.
Util-linux does not use the freshly installed headers and
libraries from the /tools
directory by default. This is fixed by altering the configure
script:
sed -i 's@/usr/include@/tools/include@g' configure
Prepare Util-linux for compilation:
./configure
Compile some support routines:
make -C lib
Only a few of the utilities contained in this package need to be built:
make -C mount mount umount make -C text-utils more
This package does not come with a test suite.
Copy these programs to the temporary tools directory:
cp -v mount/{,u}mount text-utils/more /tools/bin
Details on this package are located in Section 6.56.3, “Contents of Util-linux.”
The steps in this section are optional, but if the LFS partition is rather small, it is beneficial to learn that unnecessary items can be removed. The executables and libraries built so far contain about 70 MB of unneeded debugging symbols. Remove those symbols with:
strip --strip-debug /tools/lib/*
strip --strip-unneeded /tools/{,s}bin/*
The last of the above commands will skip some twenty files, reporting that it does not recognize their file format. Most of these are scripts instead of binaries.
Take care not to use
--strip-unneeded on the
libraries. The static ones would be destroyed and the toolchain
packages would need to be built all over again.
To save nearly 20 MB more, remove the documentation:
rm -rf /tools/{info,man}
At this point, you should have at least 850 MB of free space in
$LFS that can be used to build and
install Glibc in the next phase. If you can build and install
Glibc, you can build and install the rest too.
The commands in the remainder of this book must be performed
while logged in as user root
and no longer as user lfs.
Also, double check that $LFS is
set in root's environment.
Currently, the $LFS/tools
directory is owned by the user lfs, a user that exists only on the host
system. If the $LFS/tools
directory is kept as is, the files are owned by a user ID
without a corresponding account. This is dangerous because a
user account created later could get this same user ID and
would own the $LFS/tools
directory and all the files therein, thus exposing these files
to possible malicious manipulation.
To avoid this issue, you could add the lfs user to the new LFS system later when
creating the /etc/passwd file,
taking care to assign it the same user and group IDs as on the
host system. Better yet, change the ownership of the
$LFS/tools directory to user
root by running the following
command:
chown -R root:root $LFS/tools
Although the $LFS/tools directory
can be deleted once the LFS system has been finished, it can be
retained to build additional LFS systems of the same book version. How best
to backup $LFS/tools is a matter
of personal preference and is left as an exercise for the
reader.
If you intend to keep the temporary tools for use in building future LFS systems, now is the time to back them up. Subsequent commands in chapter 6 will alter the tools currently in place, rendering them useless for future builds.
In this chapter, we enter the building site and start constructing the LFS system in earnest. That is, we chroot into the temporary mini Linux system, make a few final preparations, and then begin installing the packages.
The installation of this software is straightforward. Although in many cases the installation instructions could be made shorter and more generic, we have opted to provide the full instructions for every package to minimize the possibilities for mistakes. 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 every installed package, a summary of its contents is given, followed by concise descriptions of each program and library the package installed.
If using compiler optimizations, please review the optimization
hint at
http://www.linuxfromscratch.org/hints/downloads/files/optimization.txt.
Compiler optimizations can make a program run slightly faster,
but they may also cause compilation difficulties and problems
when running the program. If a package refuses to compile when
using optimization, try to compile it without optimization and
see if that fixes the problem. Even if the package does compile
when using optimization, there is the risk it may have been
compiled incorrectly because of the complex interactions
between the code and build tools. Also note that the
-march and -mtune options may cause problems with the
toolchain packages (Binutils, GCC and Glibc). The small
potential gains achieved in using compiler optimizations are
often outweighed by the risks. First-time builders of LFS are
encouraged to build without custom optimizations. The
subsequent system will still run very fast and be stable at the
same time.
The order that packages are installed in this chapter needs to
be strictly followed to ensure that no program accidentally
acquires a path referring to /tools hard-wired into it. For the same
reason, do not compile packages in parallel. Compiling in
parallel may save time (especially on dual-CPU machines), but
it could result in a program containing a hard-wired path to
/tools, which will cause the
program to stop working when that directory is removed.
Before the installation instructions, each installation page provides information about the package, including a concise description of what it contains, approximately how long it will take to build, and how much disk space is required during this building process. Following the installation instructions, there is a list of programs and libraries (along with brief descriptions of these) that the package installs.
Various file systems exported by the kernel are used to communicate to and from the kernel itself. These file systems are virtual in that no disk space is used for them. The content of the file systems resides in memory.
Begin by creating directories onto which the file systems will be mounted:
mkdir -pv $LFS/{dev,proc,sys}
When the kernel boots the system, it requires the presence of
a few device nodes, in particular the console and null devices. The device nodes will be
created on the hard disk so that they are available before
udevd has been
started, and additionally when Linux is started with
init=/bin/bash.
Create the devices by running the following commands:
mknod -m 600 $LFS/dev/console c 5 1 mknod -m 666 $LFS/dev/null c 1 3
The recommended method of populating the /dev directory with devices is to mount a
virtual filesystem (such as tmpfs) on the /dev directory, and allow the devices to be
created dynamically on that virtual filesystem as they are
detected or accessed. This is generally done during the boot
process by Udev. Since this new system does not yet have Udev
and has not yet been booted, it is necessary to mount and
populate /dev manually. This is
accomplished by bind mounting the host system's /dev directory. A bind mount is a special
type of mount that allows you to create a mirror of a
directory or mount point to some other location. Use the
following command to achieve this:
mount -v --bind /dev $LFS/dev
Package Management is an often requested addition to the LFS Book. A Package Manager allows tracking the installation of files making it easy to remove and upgrade packages. Before you begin to wonder, NO—this section will not talk about nor recommend any particular package manager. What it provides is a roundup of the more popular techniques and how they work. The perfect package manager for you may be among these techniques or may be a combination of two or more of these techniques. This section briefly mentions issues that may arise when upgrading packages.
Some reasons why no package manager is mentioned in LFS or BLFS include:
Dealing with package management takes the focus away from the goals of these books—teaching how a Linux system is built.
There are multiple solutions for package management, each having its strengths and drawbacks. Including one that satisfies all audiences is difficult.
There are some hints written on the topic of package management. Visit the Hints subproject and see if one of them fits your need.
A Package Manager makes it easy to upgrade to newer versions when they are released. Generally the instructions in the LFS and BLFS Book can be used to upgrade to the newer versions. Here are some points that you should be aware of when upgrading packages, especially on a running system.
If one of the toolchain packages (Glibc, GCC or Binutils) needs to be upgraded to a newer minor version, it is safer to rebuild LFS. Though you may be able to get by rebuilding all the packages in their dependency order, we do not recommend it. For example, if glibc-2.2.x needs to be updated to glibc-2.3.x, it is safer to rebuild. For micro version updates, a simple reinstallation usually works, but is not guaranteed. For example, upgrading from glibc-2.3.4 to glibc-2.3.5 will not usually cause any problems.
If a package containing a shared library is updated,
and if the name of the library changes, then all the
packages dynamically linked to the library need to be
recompiled to link against the newer library. (Note
that there is no correlation between the package
version and the name of the library.) For example,
consider a package foo-1.2.3 that installs a shared
library with name libfoo.so.1. Say you upgrade the
package to a newer version foo-1.2.4 that installs a
shared library with name libfoo.so.2. In this case, all
packages that are dynamically linked to libfoo.so.1 need to be recompiled to
link against libfoo.so.2.
Note that you should not remove the previous libraries
until the dependent packages are recompiled.
The following are some common package management techniques. Before making a decision on a package manager, do some research on the various techniques, particularly the drawbacks of the particular scheme.
Yes, this is a package management technique. Some folks do not find the need for a package manager because they know the packages intimately and know what files are installed by each package. Some users also do not need any package management because they plan on rebuilding the entire system when a package is changed.
This is a simplistic package management that does not need
any extra package to manage the installations. Each package
is installed in a separate directory. For example, package
foo-1.1 is installed in /usr/pkg/foo-1.1 and a symlink is made
from /usr/pkg/foo to
/usr/pkg/foo-1.1. When
installing a new version foo-1.2, it is installed in
/usr/pkg/foo-1.2 and the
previous symlink is replaced by a symlink to the new
version.
Environment variables such as PATH, LD_LIBRARY_PATH, MANPATH, INFOPATH
and CPPFLAGS need to be expanded
to include /usr/pkg/foo. For
more than a few packages, this scheme becomes unmanageable.
This is a variation of the previous package management
technique. Each package is installed similar to the
previous scheme. But instead of making the symlink, each
file is symlinked into the /usr hierarchy. This removes the need to
expand the environment variables. Though the symlinks can
be created by the user to automate the creation, many
package managers have been written using this approach. A
few of the popular ones include Stow, Epkg, Graft, and
Depot.
The installation needs to be faked, so that the package
thinks that it is installed in /usr though in reality it is installed in
the /usr/pkg hierarchy.
Installing in this manner is not usually a trivial task.
For example, consider that you are installing a package
libfoo-1.1. The following instructions may not install the
package properly:
./configure --prefix=/usr/pkg/libfoo/1.1 make make install
The installation will work, but the dependent packages may
not link to libfoo as you would expect. If you compile a
package that links against libfoo, you may notice that it
is linked to /usr/pkg/libfoo/1.1/lib/libfoo.so.1
instead of /usr/lib/libfoo.so.1 as you would expect.
The correct approach is to use the DESTDIR strategy to fake installation of the
package. This approach works as follows:
./configure --prefix=/usr make make DESTDIR=/usr/pkg/libfoo/1.1 install
Most packages support this approach, but there are some
which do not. For the non-compliant packages, you may
either need to manually install the package, or you may
find that it is easier to install some problematic packages
into /opt.
In this technique, a file is timestamped before the installation of the package. After the installation, a simple use of the find command with the appropriate options can generate a log of all the files installed after the timestamp file was created. A package manager written with this approach is install-log.
Though this scheme has the advantage of being simple, it has two drawbacks. If, during installation, the files are installed with any timestamp other than the current time, those files will not be tracked by the package manager. Also, this scheme can only be used when one package is installed at a time. The logs are not reliable if two packages are being installed on two different consoles.
In this approach, a library is preloaded before installation. During installation, this library tracks the packages that are being installed by attaching itself to various executables such as cp, install, mv and tracking the system calls that modify the filesystem. For this approach to work, all the executables need to be dynamically linked without the suid or sgid bit. Preloading the library may cause some unwanted side-effects during installation. Therefore, it is advised that one performs some tests to ensure that the package manager does not break anything and logs all the appropriate files.
In this scheme, the package installation is faked into a separate tree as described in the Symlink style package management. After the installation, a package archive is created using the installed files. This archive is then used to install the package either on the local machine or can even be used to install the package on other machines.
This approach is used by most of the package managers found in the commercial distributions. Examples of package managers that follow this approach are RPM (which, incidentally, is required by the Linux Standard Base Specification), pkg-utils, Debian's apt, and Gentoo's Portage system. A hint describing how to adopt this style of package management for LFS systems is located at http://www.linuxfromscratch.org/hints/downloads/files/fakeroot.txt.
This scheme, unique to LFS, was devised by Matthias Benkmann, and is available from the Hints Project. In this scheme, each package is installed as a separate user into the standard locations. Files belonging to a package are easily identified by checking the user ID. The features and shortcomings of this approach are too complex to describe in this section. For the details please see the hint at http://www.linuxfromscratch.org/hints/downloads/files/more_control_and_pkg_man.txt.
It is time to enter the chroot environment to begin building
and installing the final LFS system. As user root, run the following command to enter
the realm that is, at the moment, populated with only the
temporary tools:
chroot "$LFS" /tools/bin/env -i \
HOME=/root TERM="$TERM" PS1='\u:\w\$ ' \
PATH=/bin:/usr/bin:/sbin:/usr/sbin:/tools/bin \
/tools/bin/bash --login +h
The -i option given to
the env command
will clear all variables of the chroot environment. After that,
only the HOME, TERM, PS1, and
PATH variables are set again. The
TERM=$TERM construct
will set the TERM variable inside
chroot to the same value as outside chroot. This variable is
needed for programs like vim and less to operate properly. If
other variables are needed, such as CFLAGS or CXXFLAGS,
this is a good place to set them again.
From this point on, there is no need to use the LFS variable anymore, because all work will be
restricted to the LFS file system. This is because the Bash
shell is told that $LFS is now
the root (/) directory.
Notice that /tools/bin comes last
in the PATH. This means that a
temporary tool will no longer be used once its final version is
installed. This occurs when the shell does not
“remember” the locations
of executed binaries—for this reason, hashing is switched
off by passing the +h
option to bash.
Note that the bash prompt will say
I have no name! This is
normal because the /etc/passwd
file has not been created yet.
It is important that all the commands throughout the remainder of this chapter and the following chapters are run from within the chroot environment. If you leave this environment for any reason (rebooting for example), ensure that the virtual kernel filesystems are mounted as explained in Section 6.2.2, “Mounting and Populating /dev” and Section 6.2.3, “Mounting Virtual Kernel File Systems” and enter chroot again before continuing with the installation.
It is time to create some structure in the LFS file system. Create a standard directory tree by issuing the following commands:
mkdir -pv /{bin,boot,etc/opt,home,lib,mnt,opt}
mkdir -pv /{media/{floppy,cdrom},sbin,srv,var}
install -dv -m 0750 /root
install -dv -m 1777 /tmp /var/tmp
mkdir -pv /usr/{,local/}{bin,include,lib,sbin,src}
mkdir -pv /usr/{,local/}share/{doc,info,locale,man}
mkdir -v /usr/{,local/}share/{misc,terminfo,zoneinfo}
mkdir -pv /usr/{,local/}share/man/man{1..8}
for dir in /usr /usr/local; do
ln -sv share/{man,doc,info} $dir
done
mkdir -v /var/{lock,log,mail,run,spool}
mkdir -pv /var/{opt,cache,lib/{misc,locate},local}
Directories are, by default, created with permission mode 755,
but this is not desirable for all directories. In the commands
above, two changes are made—one to the home directory of
user root, and another to the
directories for temporary files.
The first mode change ensures that not just anybody can enter
the /root directory—the
same as a normal user would do with his or her home directory.
The second mode change makes sure that any user can write to
the /tmp and /var/tmp directories, but cannot remove
another user's files from them. The latter is prohibited by the
so-called “sticky bit,”
the highest bit (1) in the 1777 bit mask.
The directory tree is based on the Filesystem Hierarchy
Standard (FHS) (available at http://www.pathname.com/fhs/).
In addition to the FHS, we create compatibility symlinks for
the man, doc, and info
directories since many packages still try to install their
documentation into /usr/<directory> or /usr/local/<directory> as opposed to
/usr/share/<directory> or
/usr/local/share/<directory>. The FHS
also stipulates the existence of /usr/local/games and /usr/share/games. The FHS is not precise as
to the structure of the /usr/local/share subdirectory, so we create
only the directories that are needed. However, feel free to
create these directories if you prefer to conform more
strictly to the FHS.
Some programs use hard-wired paths to programs which do not exist yet. In order to satisfy these programs, create a number of symbolic links which will be replaced by real files throughout the course of this chapter after the software has been installed:
ln -sv /tools/bin/{bash,cat,echo,grep,pwd,stty} /bin
ln -sv /tools/bin/perl /usr/bin
ln -sv /tools/lib/libgcc_s.so{,.1} /usr/lib
ln -sv /tools/lib/libstdc++.so{,.6} /usr/lib
ln -sv bash /bin/sh
A proper Linux system maintains a list of the mounted file
systems in the file /etc/mtab.
Normally, this file would be created when we mount a new file
system. Since we will not be mounting any file systems inside
our chroot environment, create an empty file for utilities that
expect the presence of /etc/mtab:
touch /etc/mtab
In order for user root to be
able to login and for the name “root” to be recognized, there must be
relevant entries in the /etc/passwd and /etc/group files.
Create the /etc/passwd file by
running the following command:
cat > /etc/passwd << "EOF"
root:x:0:0:root:/root:/bin/bash
nobody:x:99:99:Unprivileged User:/dev/null:/bin/false
EOF
The actual password for root
(the “x” used here is
just a placeholder) will be set later.
Create the /etc/group file by
running the following command:
cat > /etc/group << "EOF"
root:x:0:
bin:x:1:
sys:x:2:
kmem:x:3:
tty:x:4:
tape:x:5:
daemon:x:6:
floppy:x:7:
disk:x:8:
lp:x:9:
dialout:x:10:
audio:x:11:
video:x:12:
utmp:x:13:
usb:x:14:
cdrom:x:15:
mail:x:34:
nogroup:x:99:
EOF
The created groups are not part of any standard—they are
groups decided on in part by the requirements of the Udev
configuration in this chapter, and in part by common convention
employed by a number of existing Linux distributions. The Linux
Standard Base (LSB, available at http://www.linuxbase.org)
recommends only that, besides the group root with a Group ID (GID) of 0, a group
bin with a GID of 1 be present.
All other group names and GIDs can be chosen freely by the
system administrator since well-written programs do not depend
on GID numbers, but rather use the group's name.
To remove the “I have no
name!” prompt, start a new shell. Since a full
Glibc was installed in Chapter
5 and the /etc/passwd and
/etc/group files have been
created, user name and group name resolution will now work:
exec /tools/bin/bash --login +h
Note the use of the +h
directive. This tells bash not to use its internal
path hashing. Without this directive, bash would remember the paths
to binaries it has executed. To ensure the use of the newly
compiled binaries as soon as they are installed, the +h directive will be used for the
duration of this chapter.
The login, agetty, and init programs (and others) use a number of log files to record information such as who was logged into the system and when. However, these programs will not write to the log files if they do not already exist. Initialize the log files and give them proper permissions:
touch /var/run/utmp /var/log/{btmp,lastlog,wtmp}
chgrp -v utmp /var/run/utmp /var/log/lastlog
chmod -v 664 /var/run/utmp /var/log/lastlog
The /var/run/utmp file records
the users that are currently logged in. The /var/log/wtmp file records all logins and
logouts. The /var/log/lastlog
file records when each user last logged in. The /var/log/btmp file records the bad login
attempts.
The Linux API Headers expose the kernel's API for use by Glibc.
The Linux kernel needs to expose an Application Programming Interface (API) for the system's C library (Glibc in LFS) to utilize. This is done by way of sanitizing various C header files that are shipped in the Linux kernel source tarball.
Apply a sed
subsitution to suppress the installation of header files in
/usr/include/scsi. The versions
provided by Glibc will be used instead:
sed -i '/scsi/d' include/Kbuild
Install the header files:
make mrproper make headers_check make INSTALL_HDR_PATH=dest headers_install cp -rv dest/include/* /usr/include
The Man-pages package contains over 3,000 man pages.
Install Man-pages by running:
make install
The Glibc package contains the main C library. This library provides the basic routines for allocating memory, searching directories, opening and closing files, reading and writing files, string handling, pattern matching, arithmetic, and so on.
Some packages outside of LFS suggest installing GNU
libiconv in order to translate data from one encoding to
another. The project's home page (http://www.gnu.org/software/libiconv/)
says “This library provides an
iconv() implementation, for
use on systems which don't have one, or whose
implementation cannot convert from/to
Unicode.” Glibc provides an iconv() implementation and can convert
from/to Unicode, therefore libiconv is not required on an
LFS system.
The Glibc build system is self-contained and will install
perfectly, even though the compiler specs file and linker are
still pointing at /tools. The
specs and linker cannot be adjusted before the Glibc install
because the Glibc autoconf tests would give false results and
defeat the goal of achieving a clean build.
The glibc-libidn tarball adds support for internationalized
domain names (IDN) to Glibc. Many programs that support IDN
require the full libidn
library, not this add-on (see
http://www.linuxfromscratch.org/blfs/view/svn/general/libidn.html).
Unpack the tarball from within the Glibc source directory:
tar -xvf ../glibc-libidn-2.5.1.tar.gz mv glibc-libidn-2.5.1 libidn
In the vi_VN.TCVN locale, bash enters an infinite loop at startup. It is unknown whether this is a bash bug or a Glibc problem. Disable installation of this locale in order to avoid the problem:
sed -i '/vi_VN.TCVN/d' localedata/SUPPORTED
When running make
install, a script called test-installation.pl performs a small
sanity test on our newly installed Glibc. However, because
our toolchain still points to the /tools directory, the sanity test would be
carried out against the wrong Glibc. We can force the script
to check the Glibc we have just installed with the following:
sed -i \
's|libs -o|libs -L/usr/lib -Wl,-dynamic-linker=/lib/ld-linux.so.2 -o|' \
scripts/test-installation.pl
The ldd shell script contains Bash-specific syntax. Change it's default program interpreter to /bin/bash in case another /bin/sh is installed as described in the Shells chapter of the BLFS book:
sed -i 's|@BASH@|/bin/bash|' elf/ldd.bash.in
The Glibc documentation recommends building Glibc outside of the source directory in a dedicated build directory:
mkdir -v ../glibc-build cd ../glibc-build
Prepare Glibc for compilation:
../glibc-2.5.1/configure --prefix=/usr \
--disable-profile --enable-add-ons \
--enable-kernel=2.6.0 --libexecdir=/usr/lib/glibc
The meaning of the new configure options:
--libexecdir=/usr/lib/glibc
This changes the location of the pt_chown program from
its default of /usr/libexec to /usr/lib/glibc.
Compile the package:
make
In this section, the test suite for Glibc is considered critical. Do not skip it under any circumstance.
Test the results:
make -k check 2>&1 | tee glibc-check-log grep Error glibc-check-log
You will probably see an expected (ignored) failure in the posix/annexc test. In addition the Glibc test suite is somewhat dependent on the host system. This is a list of the most common issues:
The nptl/tst-cancel1 test will fail when using the 4.1 series of GCC.
The nptl/tst-clock2 and tst-attr3 tests sometimes fail. The reason is not completely understood, but indications are that a heavy system load can trigger these failures.
The math tests sometimes fail when running on systems where the CPU is not a relatively new genuine Intel or authentic AMD processor.
If you have mounted the LFS partition with the
noatime option,
the atime test
will fail. As mentioned in Section 2.4,
“Mounting the New Partition”, do not
use the noatime
option while building LFS.
When running on older and slower hardware or on systems under load, some tests can fail because of test timeouts being exceeded.
Though it is a harmless message, the install stage of Glibc
will complain about the absence of /etc/ld.so.conf. Prevent this warning with:
touch /etc/ld.so.conf
Install the package:
make install
The locales that can make the system respond in a different language were not installed by the above command. None of the locales are required, but if some of them are missing, testsuites of the future packages would skip important testcases.
Individual locales can be installed using the localedef program. E.g.,
the first localedef command below
combines the /usr/share/i18n/locales/de_DE
charset-independent locale definition with the /usr/share/i18n/charmaps/ISO-8859-1.gz
charmap definition and appends the result to the /usr/lib/locale/locale-archive file. The
following instructions will install the minimum set of
locales necessary for the optimal coverage of tests:
mkdir -pv /usr/lib/locale localedef -i de_DE -f ISO-8859-1 de_DE localedef -i de_DE@euro -f ISO-8859-15 de_DE@euro localedef -i en_HK -f ISO-8859-1 en_HK localedef -i en_PH -f ISO-8859-1 en_PH localedef -i en_US -f ISO-8859-1 en_US localedef -i en_US -f UTF-8 en_US.UTF-8 localedef -i es_MX -f ISO-8859-1 es_MX localedef -i fa_IR -f UTF-8 fa_IR localedef -i fr_FR -f ISO-8859-1 fr_FR localedef -i fr_FR@euro -f ISO-8859-15 fr_FR@euro localedef -i fr_FR -f UTF-8 fr_FR.UTF-8 localedef -i it_IT -f ISO-8859-1 it_IT localedef -i ja_JP -f EUC-JP ja_JP
In addition, install the locale for your own country, language and character set.
Alternatively, install all locales listed in the glibc-2.5.1/localedata/SUPPORTED file (it
includes every locale listed above and many more) at once
with the following time-consuming command:
make localedata/install-locales
Then use the localedef command to create
and install locales not listed in the glibc-2.5.1/localedata/SUPPORTED file in
the unlikely case if you need them.
The /etc/nsswitch.conf file
needs to be created because, although Glibc provides defaults
when this file is missing or corrupt, the Glibc defaults do
not work well in a networked environment. The time zone also
needs to be configured.
Create a new file /etc/nsswitch.conf by running the
following:
cat > /etc/nsswitch.conf << "EOF"
# Begin /etc/nsswitch.conf
passwd: files
group: files
shadow: files
hosts: files dns
networks: files
protocols: files
services: files
ethers: files
rpc: files
# End /etc/nsswitch.conf
EOF
One way to determine the local time zone, run the following script:
tzselect
After answering a few questions about the location, the
script will output the name of the time zone (e.g.,
America/Edmonton).
There are also some other possible timezones listed in
/usr/share/zoneinfo such as
Canada/Eastern or
EST5EDT that are not
identified by the script but can be used.
Then create the /etc/localtime
file by running:
cp -v --remove-destination /usr/share/zoneinfo/<xxx> \
/etc/localtime
Replace <xxx>
with the name of the time zone selected (e.g.,
Canada/Eastern).
The meaning of the cp option:
--remove-destination
This is needed to force removal of the already existing
symbolic link. The reason for copying the file instead
of using a symlink is to cover the situation where
/usr is on a separate
partition. This could be important when booted into
single user mode.
By default, the dynamic loader (/lib/ld-linux.so.2) searches through
/lib and /usr/lib for dynamic libraries that are
needed by programs as they are run. However, if there are
libraries in directories other than /lib and /usr/lib, these need to be added to the
/etc/ld.so.conf file in order
for the dynamic loader to find them. Two directories that are
commonly known to contain additional libraries are
/usr/local/lib and /opt/lib, so add those directories to the
dynamic loader's search path.
Create a new file /etc/ld.so.conf by running the following:
cat > /etc/ld.so.conf << "EOF"
# Begin /etc/ld.so.conf
/usr/local/lib
/opt/lib
# End /etc/ld.so.conf
EOF
|
Can be used to create a stack trace when a program terminates with a segmentation fault |
|
|
Generates message catalogues |
|
|
Displays the system configuration values for file system specific variables |
|
|
Gets entries from an administrative database |
|
|
Performs character set conversion |
|
|
Creates fastloading iconv module configuration files |
|
|
Configures the dynamic linker runtime bindings |
|
|
Reports which shared libraries are required by each given program or shared library |
|
|
Assists ldd with object files |
|
|
Prints various information about the current locale |
|
|
Compiles locale specifications |
|
|
Reads and interprets a memory trace file and displays a summary in human-readable format |
|
|
A daemon that provides a cache for the most common name service requests |
|
|
Dumps information generated by PC profiling |
|
|
A helper program for grantpt to set the owner, group and access permissions of a slave pseudo terminal |
|
|
Generates C code to implement the Remote Procecure Call (RPC) protocol |
|
|
Makes an RPC call to an RPC server |
|
|
A statically linked ln program |
|
|
Reads and displays shared object profiling data |
|
|
Asks the user about the location of the system and reports the corresponding time zone description |
|
|
Traces the execution of a program by printing the currently executed function |
|