User:Variable Username/sandbox
Chapter 1. Introduction
Host System Requirements
- Linux
- Bash-3.2
- Binutils-2.17
- Bison-2.3
- Bzip2-1.0.4
- Coreutils-6.9
- Diffutils-2.8.1
- Findutils-4.2.31
- Gawk-4.0.1
- GCC-4.7
- Glibc-2.11
- Grep-2.5.1a
- Gzip-1.3.12
- Linux Kernel-2.6.32
- M4-1.4.10
- Make-3.81
- Patch-2.5.4
- Perl-5.8.8
- Sed-4.1.5
- Tar-1.22
- Texinfo-4.7
- Xz-5.0.0
To check the system requirements run version-check.sh.
To check library consistency run library-check.sh.
Chapter 2. Preparing the Host System
Creating a new partition
A minimal system requires a partition of around 6 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. A 20 GB partition is a reasonable size to provide for growth. The LFS system itself will not take up this much room. A large portion of this requirement is to provide sufficient free temporary storage as well as for adding additional capabilities after LFS is complete. Additionally, 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/sda 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.
Creating a file system on the partition
LFS assumes that the root file system (/) is of type ext4. To create an ext4 file system on the LFS partition, run the following:
mkfs -v -t ext4 /dev/<xxx>
Setting the $LFS variable
Throughout this guide, the environment variable LFS will be used several times. You should ensure that this variable is always defined throughout the LFS build process. It should be set to the name of the directory where you will be building your LFS system - we will use /mnt/lfs as an example, but the directory choice is up to you. If you are building LFS on a separate partition, this directory will be the mount point for the partition. Choose a directory location and set the variable with the following command:
export LFS=/mnt/lfs
Having this variable set is beneficial in that commands such as mkdir -v $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 (such as when doing a su to root or another user). Check that the LFS variable is set up properly with:
echo $LFS
Make sure the output shows the path to your LFS system's build location, which is /mnt/lfs if the provided example was followed. If the output is incorrect, use the command given earlier on this page to set $LFS to the correct directory name.
Mounting the new 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 the directory specified by the LFS environment variable as described in the previous section.
Create the mount point and mount the LFS file system by running:
mkdir -pv $LFS
mount -v -t ext4 /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 ext4 /dev/<xxx> $LFS
mkdir -v $LFS/usr
mount -v -t ext4 /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 or nodev options). Run the mount command without any parameters to see what options are set for the mounted LFS partition. If nosuid and/or nodev are set, the partition will need to be remounted.
Now that there is an established place to work, it is time to download the packages.
Chapter 3. Packages and patches
Introduction
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#packages.
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/sourcesAn easy way to download all of the packages and patches is by using wget-list as an input to wget. For example:
wget --input-file=wget-list --continue --directory-prefix=$LFS/sources
Additionally, starting with LFS-7.0, there is a seperate file, md5sums, which can be used to verify that all the correct packages are available before proceeding. Place that file in $LFS/sources and run:
pushd $LFS/sources
md5sum -c md5sums
popd
All Packages
Download or otherwise obtain the following packages:
Total size of these packages: about 414 MB
Needed Patches
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:
Total size of these patches: about 190.7 KB
Chapter 4. Final Preparations
Introduction
In this chapter, we will perform a few additional tasks to prepare for building the temporary system. We will create a directory in $LFS for the installation of the temporary tools, add an unprivileged user to reduce risk, and create an appropriate build environment for that user. We will also explain the unit of time we use to measure how long LFS packages take to build, or “SBUs”, and give some information about package test suites.
Creating the $LFS/tools directory
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 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 Chapter 5 (when we are still using some tools from the host) and in the next (when we are “chrooted” to the LFS partition).
Adding the LFS User
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 seperate working directory was created as suggested, give user lfs ownership of this directory:
chown -v $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.
Setting up the environment
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
LFS_TGT=$(uname -m)-lfs-linux-gnu
PATH=/tools/bin:/bin:/usr/bin
export LFS LC_ALL LFS_TGT 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. Setting LC_ALL to “POSIX” or “C” (the two are equivalent) ensures that everything will work as expected in the chroot environment.
The LFS_TGT variable sets a non-default, but compatible machine description for use when building our cross compiler and linker and when cross compiling our temporary toolchain. More information is contained in Section 5.2, “Toolchain Technical Notes”.
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
About SBUs
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. 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.
About the test suites
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 at http://www.linuxfromscratch.org/lfs/faq.html#no-ptys.
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/7.10/ to verify whether or not these failures are expected. This site is valid for all tests throughout this book.
Chapter 5. Constructing a temporary system
Introduction
This chapter shows how to build 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.
Toolchain Technical Notes
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 to at any time during the process.
The overall goal of Chapter 5 is to produce a temporary area that contains a known-good set of tools that can be isolated from the host system. By using chroot, the commands in the remaining chapters will be contained within that environment, ensuring a clean, trouble-free build of the target LFS system. The build process has been designed to minimize the risks for new readers and to provide the most educational value at the same time.
Note: Before continuing, be aware of the name of the working platform, often referred to as the target triplet. 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. For example, for a 32-bit Intel processor the output will be i686-pc-linux-gnu. On a 64-bit system it will be x86_64-pc-linux-gnu.
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 for a 32-bit Intel machine will be ld-linux.so.2 (ld-linux-x86-64.so.2 for 64-bit systems). A sure-fire way to determine the name of the dynamic linker 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:
- Slightly adjusting the name of the working platform, by changing the "vendor" field target triplet by way of the LFS_TGT variable, ensures that the first build of Binutils and GCC produces a compatible cross-linker and cross-compiler. Instead of producing binaries for another architecture, the cross-linker and cross-compiler will produce binaries compatible with the current hardware.
- The temporary libraries are cross-compiled. Because a cross-compiler by its nature cannot rely on anything from its host system, this method removes potential contamination of the target system by lessening the chance of headers or libraries from the host being incorporated into the new tools. Cross-compilation also allows for the possibility of building both 32-bit and 64-bit libraries on 64-bit capable hardware.
- Careful manipulation of the GCC source 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/$LFS_TGT/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-lfs-linux-gnu/bin/as
checking what linker to use... /tools/i686-lfs-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.
Next installed are sanitized Linux API headers. These allow the standard C library (Glibc) to interface with features that the Linux kernel will provide.
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 compiler relating to the --host parameter passed to its configure script; e.g. in our case, the compiler will be i686-lfs-linux-gnu-gcc. 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="i686-lfs-gnu-gcc" 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.
During the second pass of Binutils, we are able to utilize the --with-lib-path configure switch to control ld's library search path.
For the second pass of GCC, its sources also need to be modified to tell GCC to use the new dynamic linker. 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. 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, we will perform a quick changeover of the toolchain defaults, and then proceed in building the rest of the target LFS system.
General Compilation Instructions
When building packages there are several assumptions made within the instructions:
- 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.
- Check one last time that the LFS environment variable is set up properly:
echo $LFSMake sure the output shows the path to the LFS partition's mount point, which is /mnt/lfs, using our example. - Finally, two last important items must be emphasized:
Important: The build instructions assume that the Host System Requirements, including symbolic links, have been set properly:
- bash is the shell in use.
- sh is a symbolic link to bash.
- /usr/bin/awk is a symbolic link to gawk.
- /usr/bin/yacc is a symbolic link to bison or a small script that executes bison.
Important: To re-emphasize the build process:
- Place all the sources and patches in a directory that will be accessible from the chroot environment such as /mnt/lfs/sources/. Do 'not' put sources in /mnt/lfs/tools/.
- Change to the sources directory
- For each package
- Using the tar program, extract the package to be built. In Chapter 5, ensure you are the 'lfs' user when extracting the package.
- Change to the directory created when the package was extracted.
- Follow the instruction for building the package.
- Change back to the sources directory.
- Delete the extracted source directory unless instructed otherwise.
Binutils-2.27 - Pass 1
The Binutils package contains a linker, an assembler, and other tools for handling object files.
Approximate build time: 1 SBU
Required disk space: 519MB
Installation of Cross Binutils
Note: Go back and re-read the notes in the previous section. Understanding the notes labled important will save you a lot of problems later.
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 reccomends building Binutils in a dedicated build directory:
mkdir -v build
cd build
Note: 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 commands in a time command like this: time { ./configure ... && ... && make install; }.
Note: The approximate build SBU values and required disk space in Chapter 5 does not include test suite data.
Now prepare Binutils for compilation:
../configure --prefix=/tools \
--with-sysroot=$LFS \
--with-lib-path=/tools/lib \
--target=$LFS_TGT \
--disable-nls \
--disable-werror
The meaning of the configure options:
- --prefix=/tools
- This tells the configure script to prepare to install the Binutils programs in the /tools directory
- --with-sysroot=$LFS
- For cross compilation, this tells the build system to look in $LFS for the target system libraries as needed.
- --with-lib-path=/tools/lib
- This specifies which library path the linker should be configured to use.
- --target=$LFS_TGT
- Because the machine description in the LFS_TGT variable is slightly different than the value returned by the config.guess script, this switch will tell the configure script to adjust Binutil's build system for building a cross linker.
- --disable-nls
- This disables internationalization as i18n is not needed for the temporary tools.
- --disable-werror
- This prevents the build from stopping in the event that there are warnings from the host's conpiler.
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.
If building on x86_64, create a symlink to ensure the sanity of the toolchain:
case $(uname -m) in
x86_64) mkdir -v /tools/lib && ln -sv lib /tools/lib64 ;;
esac
Install the package:
make install
GCC-6.2.0 - Pass 1
The GCC package contains the GNU compiler collection, which includes the C and C++ compilers.
Approximate build time: 8.3 SBU
Required disk space: 2.5 GB
Installation of Cross GCC
GCC now requires the GMP, MPFR and MPC packages. As these packages may not be included in your host distribution, they will be built with GCC. Unpack each package into the GCC source directory and rename the resulting directories so the GCC build procedures will automatically use them:
Note: There are frequent misunderstandings about this chapter. The procedures are the same as every other chapter as explained earlier. First extract the gcc tarball from the sources directory and then change to the directory created. Only then should you proceed with the instructions below.
tar -xf ../mpfr-3.1.4.tar.xz
mv -v mpfr-3.1.4 mpfr
tar -xf ../gmp-6.1.1.tar.xz
mv -v gmp-6.1.1 gmp
tar -xf ../mpc-1.0.3.tar.gz
mv -v mpc-1.0.3 mpc
The following command will change the location of GCC's default dynamic linker to use the one installed in /tools. It also removes /usr/include from GCC's include search path. Issue:
for file in \
$(find gcc/config -name linux64.h -o -name linux.h -o -name sysv4.h)
do
cp -uv $file{,.orig}
sed -e 's@/lib\(64\)\?\(32\)\?/ld@/tools&@g' \
-e 's@/usr@/tools@g' $file.orig > $file
echo '
#undef STANDARD_STARTFILE_PREFIX_1
#undef STANDARD_STARTFILE_PREFIX_2
#define STANDARD_STARTFILE_PREFIX_1 "/tools/lib/"
#define STANDARD_STARTFILE_PREFIX_2 ""' >> $file
touch $file.orig
done
In case the above seems hard to follow, let's break it down a bit. First we find all the files under the gcc/config directory that are named either linux.h, linux64.h or sysv4.h. For each file found, we copy it to a file of the same name but with an added suffix of “.orig”. Then the first sed expression prepends “/tools” to every instance of “/lib/ld”, “/lib64/ld” or “/lib32/ld”, while the second one replaces hard-coded instances of “/usr”. Next, we add our define statements which alter the default startfile prefix to the end of the file. Note that the trailing “/” in “/tools/lib/” is required. Finally, we use touch to update the timestamp on the copied files. When used in conjunction with cp -u, this prevents unexpected changes to the original files in case the commands are inadvertently run twice.
The GCC documentation recommends building GCC in a dedicated build directory:
mkdir -v build
cd build
Prepare GCC for compilation:
../configure \
--target=$LFS_TGT \
--prefix=/tools \
--with-glibc-version=2.11 \
--with-sysroot=$LFS \
--with-newlib \
--without-headers \
--with-local-prefix=/tools \
--with-native-system-header-dir=/tools/include \
--disable-nls \
--disable-shared \
--disable-multilib \
--disable-decimal-float \
--disable-threads \
--disable-libatomic \
--disable-libgomp \
--disable-libmpx \
--disable-libquadmath \
--disable-libssp \
--disable-libvtv \
--disable-libstdcxx \
--enable-languages=c,c++
The meaning of the configure options:
- --with-newlib
- Since a working C library is not yet available, this ensures that the inhibit_libc constant is defined when building libgcc. This prevents the compiling of any code that requires libc support.
- --without-headers
- When creating a complete cross-compiler, GCC requires standard headers compatible with the target system. For our purposes these headers will not be needed. This switch prevents GCC from looking for them.
- --with-local-prefix=/tools
- The local prefix is the location in the system that GCC will search for locally installed include files. The default is /usr/local. Setting this to /tools helps keep the host location of /usr/local out of this GCC's search path.
- --with-native-system-header-dir=/tools/include
- By default GCC searches /usr/include for system headers. In conjunction with the sysroot switch, this would translate normally to $LFS/usr/include. However the headers that will be installed in the next two sections will go to $LFS/tools/include. This switch ensures that gcc will find them correctly. In the second pass of GCC, this same switch will ensure that no headers from the host system are found.
- --disable-shared
- This switch forces GCC to link its internal libraries statically. We do this to avoid possible issues with the host system.
- --disable-decimal-float, --disable-threads, --disable-libatomic, --disable-libgomp, --disable-libmpx, --disable-libquadmath, --disable-libssp, --disable-libvtv, --disable-libstdcxx
- These switches disable support for the decimal floating point extension, threading, libatomic, libgomp, libmpx, libquadmath, libssp, libvtv, and the C++ standard library respectively. These features will fail to compile when building a cross-compiler and are not necessary for the task of cross-compiling the temporary libc.
- --disable-multilib
- On x86_64, LFS does not yet support a multilib configuration. This switch is harmless for x86.
- --enable-languages=c,c++
- This option ensures that only the C and C++ compilers are built. These are the only languages needed now.
Compile GCC by running:
make
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
Linux-4.7.2 API Headers
The Linux API Headers (in linux-4.7.2.tar.xz) expose the kernel's API for use by Glibc.
Approximate build time: less than 0.1 SBU
Required disk space: 750 MB