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) 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.

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 or irc.linux-phreak.net. The support channel is named #LFS-support.

The mailing lists hosted at linuxfromscratch.org are also accessible via the Network News Transfer Protocol (NNTP) server. All messages posted to a mailing list are copied to the corresponding newsgroup, and vice versa.

The news server is located at news.linuxfromscratch.org.

For more information on packages, updated versions, tweaks, and personal experiences, see the LFS Wiki at http://wiki.linuxfromscratch.org/. Users can also add information there to help others with their future LFS activities.

For additional information on the packages, useful tips are available 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/ for a list of current mirrors.

Please direct all your questions and comments to one of the LFS mailing lists (see above).

Apart from a brief explanation of the problem being experienced, the essential things to include in any request for help are:

Note

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 during the stage where the configure script is run, review the config.log file. This file may contain errors encountered during configure which were not printed to the screen. Include those 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 compile issues. 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 2

In this case, many people would just include the bottom section:

make [2]: *** [make] Error 1

This 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.

Many packages provide a test suite which, depending on the importance of the package, should be run. Sometimes packages will generate false or expected failures. If these errors are encountered, check the LFS Wiki page at http://wiki.linuxfromscratch.org/ to see if we have noted and investigated these issues. If these issues are noted and addressed, there is no need to be concerned.

Besides their specific task, most programs have to perform many common and sometimes trivial operations. These include allocating memory, searching directories, reading and writing files, string handling, pattern matching, arithmetic, and other tasks. Instead of obliging each program to reinvent the wheel, the GNU system provides all these basic functions in ready-made libraries. The major library on any Linux system is Glibc.

There are two primary ways of linking the functions from a library to a program that uses them—statically or dynamically. When a program is linked statically, the code of the used functions is included in the executable, resulting in a rather bulky program. When a program is dynamically linked, it includes a reference to the dynamic linker, the name of the library, and the name of the function, resulting in a much smaller executable. A third option is to use the programming interface of the dynamic linker (see the dlopen man page for more information).

Dynamic linking is the default on Linux and has three major advantages over static linking. First, only one copy of the executable library code is needed on the hard disk, instead of having multiple copies of the same code included in several programs, thus saving disk space. Second, when several programs use the same library function at the same time, only one copy of the function's code is required in core, thus saving memory space. Third, when a library function gets a bug fixed or is otherwise improved, only the one library needs to be recompiled instead of recompiling all programs that make use of the improved function.

If dynamic linking has several advantages, why then do we statically link the first two packages in this chapter? The reasons are threefold—historical, educational, and technical. The historical reason is that earlier versions of LFS statically linked every program in this chapter. Educationally, knowing the difference between static and dynamic linking is useful. The technical benefit is a gained element of independence from the host, meaning that those programs can be used independently of the host system. However, it is worth noting that an overall successful LFS build can still be achieved when the first two packages are built dynamically.

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.

This package is known to have issues when its default optimization flags (including the -march and -mcpu options) are changed. If any environment variables that override default optimizations have been defined, such as CFLAGS and CXXFLAGS, unset them when building Binutils.

The Binutils documentation recommends building Binutils outside of the source directory in a dedicated build directory:

mkdir ../binutils-build
cd ../binutils-build

Note

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 four commands in a time command like this: time { ./configure ... && ... && ... && make install; }.

Now prepare Binutils for compilation:

../binutils-2.15.91.0.2/configure --prefix=/tools \
    --disable-nls

The meaning of the configure options:

Continue with compiling the package:

make configure-host
make LDFLAGS="-all-static"

The meaning of the make parameters:

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 LDFLAGS="-all-static" LIB_PATH=/tools/lib

The meaning of the make parameters:

Warning

Do not remove the Binutils build and source directories yet. These will be needed again in their current state later in this chapter.

Details on this package are located in the section called “Contents of Binutils”

The GCC package contains the GNU compiler collection, which includes the C and C++ compilers.

Unpack only the gcc-core tarball because neither the C++ compiler nor the test suite will be needed here.

This package is known to have issues when its default optimization flags (including the -march and -mcpu options) are changed. If any environment variables that override default optimizations have been defined, such as CFLAGS and CXXFLAGS, unset them when building GCC.

The GCC documentation recommends building GCC outside of the source directory in a dedicated build directory:

mkdir ../gcc-build
cd ../gcc-build

Prepare GCC for compilation:

../gcc-3.4.1/configure --prefix=/tools \
    --libexecdir=/tools/lib --with-local-prefix=/tools \
    --disable-nls --enable-shared --enable-languages=c

The meaning of the configure options:

Continue with compiling the package:

make BOOT_LDFLAGS="-static" bootstrap

The meaning of the make parameters:

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 -s gcc /tools/bin/cc

Details on this package are located in the section called “Contents of GCC”

The Linux-Libc-Headers package contains the “sanitized” kernel headers.

For years it has been common practice to use “raw” kernel headers (straight from a kernel tarball) in /usr/include, but over the last few years, the kernel developers have taken a strong stance that this should not be done. This gave birth to the Linux-Libc-Headers Project, which was designed to maintain an Application Programming Interface (API) stable version of the Linux headers.

Install the header files:

cp -R include/asm-i386 /tools/include/asm
cp -R include/linux /tools/include

If your architecture is not i386 (compatible), adjust the first command accordingly.

Details on this package are located in the section called “Contents of Linux-Libc-Headers”

The Linux kernel package contains the kernel source as well as the header files used by Glibc.

Because some packages need to refer to the kernel header files, now is a good time to unpack the kernel archive, set it up, and copy the required files to a place where gcc can locate them later.

Prepare for the header installation with:

make mrproper

This ensures that the kernel tree is absolutely clean. It is recommended that this command be issued prior to each kernel compilation. Do not assume that the source tree is automatically clean after un-tarring.

Create the include/linux/version.h file:

make include/linux/version.h

Create the platform-specific include/asm symlink:

make include/asm

Install the platform-specific header files:

mkdir /tools/glibc-kernheaders
cp -HR include/asm /tools/glibc-kernheaders
cp -R include/asm-generic /tools/glibc-kernheaders

Finally, install the cross-platform kernel header files:

cp -R include/linux /tools/glibc-kernheaders

Details on this package are located in the section called “Contents of Linux”

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.

This package is known to have issues when its default optimization flags (including the -march and -mcpu options) are changed. If any environment variables that override default optimizations have been defined, such as CFLAGS and CXXFLAGS, unset them when building Glibc.

It should be noted that compiling Glibc in any way other than the method suggested in this book puts the stability of the system at risk.

The Glibc documentation recommends building Glibc outside of the source directory in a dedicated build directory:

mkdir ../glibc-build
cd ../glibc-build

Next, prepare Glibc for compilation:

../glibc-2.3.4-20040701/configure --prefix=/tools \
    --disable-profile --enable-add-ons=nptl --with-tls \
    --with-__thread --enable-kernel=2.6.0 \
    --with-binutils=/tools/bin --without-gd --without-cvs \
    --with-headers=/tools/glibc-kernheaders

The meaning of the configure options:

During this stage the following warning might appear:

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 the section called “Glibc-2.3.4-20040701”

In this chapter, some tests can be adversely effected 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 /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.

Note

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 the following command:

make localedata/install-locales

To save time, an alternative to running the previous command (which generates and installs every locale Glibc is aware of) is to install only those locales that are wanted and needed. This can be achieved by using the localedef command. Information on this command is located in the INSTALL file in the Glibc source. However, there are a number of locales that are essential in order for the tests of future packages to pass, in particular, the libstdc++ tests from GCC. The following instructions, instead of the install-locales target used above, will install the minimum set of locales necessary for the tests to run successfully:

mkdir -p /tools/lib/locale
localedef -i de_DE -f ISO-8859-1 de_DE
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 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 it_IT -f ISO-8859-1 it_IT
localedef -i ja_JP -f EUC-JP ja_JP

Details on this package are located in the section called “Contents of Glibc”

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 is provided in Chapter 7.

Install the package:

make install

Warning

Do not remove the tcl8.4.7 source directory yet, as the next package will need its internal headers.

Now make a necessary symbolic link:

ln -s 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.42.1-spawn-1.patch

Now prepare Expect for compilation:

./configure --prefix=/tools --with-tcl=/tools/lib --with-x=no

The meaning of the configure options:

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:

The source directories of both Tcl and Expect can now be removed.

The DejaGNU package contains a framework for testing other programs.

Prepare DejaGNU for compilation:

./configure --prefix=/tools

Build and install the package:

make install

This package is known to have issues when its default optimization flags (including the -march and -mcpu options) are changed. If any environment variables that override default optimizations have been defined, such as CFLAGS and CXXFLAGS, unset them when building GCC.

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 Wiki at http://wiki.linuxfromscratch.org/ for more information on how to get PTYs working.

Because the C and the C++ compilers will be built, unpack both the core and the g++ tarballs (as well as test suite, if you want to run the tests). By unpacking them in the working directory, they will all unfold into a single gcc-3.4.1/ subdirectory.

First correct a known problem and make an essential adjustment:

patch -Np1 -i ../gcc-3.4.1-no_fixincludes-1.patch
patch -Np1 -i ../gcc-3.4.1-specs-1.patch

The first patch disables the GCC fixincludes script. This was briefly mentioned earlier, but a more in-depth explanation of the fixincludes process is warranted here. Under normal circumstances, the GCC fixincludes script scans the system for header files that need to be fixed. It might find that some Glibc header files on the host system need to be fixed, and will fix them and put them in the GCC private include directory. In Chapter 6, after the newer Glibc has been installed, this private include directory will be searched before the system include directory. This may result in GCC finding the fixed headers from the host system, which most likely will not match the Glibc version used for the LFS system.

The second patch changes GCC's default location of the dynamic linker (typically ld-linux.so.2). It also removes /usr/include from GCC's include search path. Patching now rather than adjusting the specs file after installation ensures that the new dynamic linker is used during the actual build of GCC. That is, all of the final (and temporary) binaries created during the build will link against the new Glibc.

Important

The above patches are critical in ensuring a successful overall build. Do not forget to apply them.

Create a separate build directory again:

mkdir ../gcc-build
cd ../gcc-build

Before starting to build GCC, remember to unset any environment variables that override the default optimization flags.

Now prepare GCC for compilation:

../gcc-3.4.1/configure --prefix=/tools \
    --libexecdir=/tools/lib --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:

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. To receive a summary of the test suite results, run:

../gcc-3.4.1/contrib/test_summary

For only the summaries, pipe the output through grep -A7 Summ.

Results can be compared to those posted to the gcc-testresults mailing list to see similar configurations to the one being built. For an example of how current GCC-3.4.1 should look on i686-pc-linux-gnu, see http://gcc.gnu.org/ml/gcc-testresults/2004-07/msg00179.html.

A few unexpected failures cannot always be avoided. The GCC developers are usually aware of these issues, but have not resolved them yet. Unless the test results are vastly different from those at the above URL, it is safe to continue.

Install the package:

make install

Note

At this point it is strongly recommended to repeat the sanity check we performed earlier in this chapter. Refer back to the section called “Adjusting the Toolchain” and repeat the test compilation. If the result is wrong, the most likely reason is that the GCC Specs patch was not properly applied.

Details on this package are located in the section called “Contents of GCC”

The Binutils package contains a linker, an assembler, and other tools for handling object files.

This package is known to have issues when its default optimization flags (including the -march and -mcpu options) are changed. If any environment variables that override default optimizations have been defined, such as CFLAGS and CXXFLAGS, unset them when building Binutils.

Create a separate build directory again:

mkdir ../binutils-build
cd ../binutils-build

Prepare Binutils for compilation:

../binutils-2.15.91.0.2/configure --prefix=/tools \
    --enable-shared --with-lib-path=/tools/lib

The meaning of the new configure option:

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

Warning

Do not remove the Binutils source and build directories yet. These directories will be needed again in the next chapter in their current state.

Details on this package are located in the section called “Contents of Binutils”

The Gawk package contains programs for manipulating text files.

Prepare Gawk for compilation:

./configure --prefix=/tools

Compile the package:

make

To test the results (not necessary), issue: make check.

Install the package:

make install

Details on this package are located in the section called “Contents of Gawk”

The Coreutils package contains utilities for showing and setting the basic system characteristics.

Prepare Coreutils for compilation:

DEFAULT_POSIX2_VERSION=199209 ./configure --prefix=/tools

This package has an issue when compiled against versions of Glibc later than 2.3.2. Some of the Coreutils utilities (such as head, tail, and sort) will reject their traditional syntax, a syntax that has been in use for approximately 30 years. This old syntax is so pervasive that compatibility should be preserved until the many places where it is used can be updated. Backwards compatibility is achieved by setting the DEFAULT_POSIX2_VERSION environment variable to “199209” in the above command. If you do not want Coreutils to be backwards compatible with the traditional syntax, then omit setting the DEFAULT_POSIX2_VERSION environment variable. It is important to remember that doing so will have consequences, including the need to patch the many packages that still use the old syntax. Therefore, it is recommended that the instructions be followed exactly as given above.

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

Details on this package are located in the section called “Contents of Coreutils”

The Bzip2 package contains programs for compressing and decompressing files. Text files yield a much better compression than with the traditional gzip.

The Bzip2 package does not contain a configure script. Compile it with:

make

Install the package:

make PREFIX=/tools install

Details on this package are located in the section called “Contents of Bzip2”

The Gzip package contains programs for compressing and decompressing files.

Prepare Gzip 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 the section called “Contents of Gzip”

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 the section called “Contents of Diffutils”

The Findutils package contains programs to find files. Processes 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 the section called “Contents of Findutils”

The Make package contains a program for compiling large 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 the section called “Contents of Make”

The Grep package contains programs for searching through files.

Prepare Grep for compilation:

./configure --prefix=/tools \
    --disable-perl-regexp --with-included-regex

The meaning of the configure options:

Compile the package:

make

To test the results, issue: make check.

Install the package:

make install

Details on this package are located in the section called “Contents of Grep”

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 the section called “Contents of Sed”

The Gettext package contains utilities for internationalization and localization. These allow programs to be compiled with NLS, enabling them to output messages in the user's native language.

Prepare Gettext for compilation:

./configure --prefix=/tools --disable-libasprintf \
    --disable-csharp

The meaning of the configure options:

Compile the package:

make

To test the results, issue: make check. This takes quite some time, around 7 SBUs. The Gettext test suite is known to experience failures under certain host conditions, for example when it finds a Java compiler on the host. An experimental patch to disable Java is available from the LFS Patches project at http://www.linuxfromscratch.org/patches/.

Install the package:

make install

Details on this package are located in the section called “Contents of Gettext”

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:

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 the section called “Contents of Ncurses”

The Patch package contains a program for modifying files.

Prepare Patch for compilation:

CPPFLAGS=-D_GNU_SOURCE ./configure --prefix=/tools

The preprocessor flag -D_GNU_SOURCE is only needed on the PowerPC platform. It can be left out on other architectures.

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 the section called “Contents of Patch”

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 the section called “Contents of Tar”

The Texinfo package contains programs for reading, writing, and converting Info documents.

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 the section called “Contents of Texinfo”

The Bash package contains the Bourne-Again SHell.

Prepare Bash for compilation:

./configure --prefix=/tools --without-bash-malloc

The meaning of the configure option:

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 -s bash /tools/bin/sh

Details on this package are located in the section called “Contents of Bash”

The M4 package contains a macro processor.

Prepare M4 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 the section called “Contents of M4”

The Bison package contains a parser generator.

Prepare Bison 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 the section called “Contents of Bison”

The Flex package contains a utility for generating programs that recognize patterns in text.

Flex contains several known bugs. These can be fixed with the following patch:

patch -Np1 -i ../flex-2.5.31-debian_fixes-2.patch

The GNU autotools will detect that the Flex source code has been modified by the previous patch and tries to update the manual page accordingly. This does not work on many systems, and the default page is fine, so make sure it does not get regenerated:

touch doc/flex.1

Now prepare Flex 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 the section called “Contents of Flex”

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. 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

Since only a couple of the utilities contained in this package are needed, build only those:

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 mount/{,u}mount text-utils/more /tools/bin

Details on this package are located in the section called “Contents of Util-linux”

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.5-libc-1.patch

Prepare Perl for compilation (make sure to get the 'IO Fcntl POSIX' part of the command correct—they are all letters):

./configure.gnu --prefix=/tools -Dstatic_ext='IO Fcntl POSIX'

The meaning of the configure option:

Compile only the required tools:

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.

Copy these tools and their libraries:

cp perl pod/pod2man /tools/bin
mkdir -p /tools/lib/perl5/5.8.5
cp -R lib/* /tools/lib/perl5/5.8.5

Details on this package are located in the section called “Contents of Perl”

The Udev package contains programs for dynamic creation of device nodes.

The udevstart program hardcodes the path to the udev program in itself, which would cause issues since udev was installed in a non-standard location. Fix this by running the following:

sed -i 's@/sbin/udev@/tools/sbin/udev@g' udevstart.c

Also, ensure that udev knows the correct location to look for its configuration files:

sed -i 's@/etc@/tools/etc@g' etc/udev/udev.conf.in

Now compile Udev:

make prefix=/tools etcdir=/tools/etc

This package does not come with a test suite.

Install the package:

make DESTDIR=/tools udevdir=/dev install

Udev's configuration is far from ideal by default, so install LFS-specific configuration files here:

cp ../udev-config-2.permissions \
    /tools/etc/udev/permissions.d/00-lfs.permissions
cp ../udev-config-1.rules /tools/etc/udev/rules.d/00-lfs.rules

Details on this package are located in the section called “Contents of Udev”

The directory tree is based on the Filesystem Hierarchy Standard (FHS) standard (available at http://www.pathname.com/fhs/). Besides the tree created above, this standard stipulates the existence of /usr/local/games and /usr/share/games. We do not recommend these for a base system, however, feel free to make the system FHS-compliant. The FHS is not precise as to the structure of the /usr/local/share subdirectory, so we created only the directories that are needed.

When the kernel boots the system, it requires the presence of a few device nodes, in particular the console and null devices. Create these by running the following commands:

mknod -m 600 /dev/console c 5 1
mknod -m 666 /dev/null c 1 3

The ideal way to populate /dev is to mount a ramfs onto /dev, like tmpfs, and create the devices on there during each bootup. Since the system has not been booted, it is necessary to do what the bootscripts would otherwise do and populate /dev. Begin by mounting /dev:

mount -n -t ramfs none /dev

Run the installed udevstart program to create the initial devices based on all the information in /sys:

/tools/sbin/udevstart

There are some symlinks and directories required by LFS that are not created by Udev, so create those here:

ln -s /proc/self/fd /dev/fd
ln -s /proc/self/fd/0 /dev/stdin
ln -s /proc/self/fd/1 /dev/stdout
ln -s /proc/self/fd/2 /dev/stderr
ln -s /proc/kcore /dev/core
mkdir /dev/pts
mkdir /dev/shm

Finally, mount the proper virtual (kernel) file systems on the newly-created directories:

mount -t devpts -o gid=4,mode=620 none /dev/pts
mount -t tmpfs none /dev/shm

The mount commands executed above may result in the following warning message:

can't open /etc/fstab: No such file or directory.

This file—/etc/fstab—has not been created yet but is also not required for the file systems to be properly mounted. As such, the warning can be safely ignored.

The Linux-Libc-Headers package contains the “sanitized” kernel headers.

For years it has been common practice to use “raw” kernel headers (straight from a kernel tarball) in /usr/include, but over the last few years, the kernel developers have taken a strong stance that this should not be done. This gave birth to the Linux-Libc-Headers Project, which was designed to maintain an API stable version of the Linux headers.

Install the header files:

cp -R include/asm-i386 /usr/include/asm
cp -R include/linux /usr/include

Ensure that all the headers are owned by root:

chown -R root:root /usr/include/{asm,linux}

Make sure the users can read the headers:

find /usr/include/{asm,linux} -type d -exec chmod 755 {} \;
find /usr/include/{asm,linux} -type f -exec chmod 644 {} \;

The Man-pages package contains over 1,200 manual 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.

This package is known to have issues when its default optimization flags (including the -march and -mcpu options) are changed. If any environment variables that override default optimizations have been defined, such as CFLAGS and CXXFLAGS, unset them when building Glibc.

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 documentation recommends building Glibc outside of the source directory in a dedicated build directory:

mkdir ../glibc-build
cd ../glibc-build

Prepare Glibc for compilation:

../glibc-2.3.4-20040701/configure --prefix=/usr \
    --disable-profile --enable-add-ons=nptl --with-tls \
    --with-__thread --enable-kernel=2.6.0 --without-cvs \
    --libexecdir=/usr/lib/glibc \
    --with-headers=/tools/glibc-kernheaders

The meaning of the new configure option:

Compile the package:

make

Important

In this section, the test suite for Glibc is considered critical. Do not skip it under any circumstance.

Test the results:

make check

The Glibc test suite is highly dependent on certain functions of the host system, in particular the kernel. In general, the Glibc test suite is always expected to pass. However, in certain circumstances, some failures are unavoidable. This is a list of the most common issues:

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. Install this with:

make localedata/install-locales

To save time, an alternative to running the previous command (which generates and installs every locale Glibc is aware of) is to install only those locales that are wanted and needed. This can be achieved by using the localedef command. Information on this command is located in the INSTALL file in the Glibc source. However, there are a number of locales that are essential in order for the tests of future packages to pass, in particular, the libstdc++ tests from GCC. The following instructions, instead of the install-locales target used above, will install the minimum set of locales necessary for the tests to run successfully:

mkdir -p /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 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 it_IT -f ISO-8859-1 it_IT
localedef -i ja_JP -f EUC-JP ja_JP

Some locales installed by the make localedata/install-locales command above are not properly supported by some applications that are in the LFS and BLFS books. Because of the various problems that arise due to application programmers making assumptions that break in such locales, LFS should not be used in locales that utilize multibyte character sets (including UTF-8) or right-to-left writing order. Numerous unofficial and unstable patches are required to fix these problems, and it has been decided by the LFS developers not to support such complex locales. This applies to the ja_JP and fa_IR locales as well—they have been installed only for GCC and Gettext tests to pass, and the watch program (part of the Procps package) does not work properly in them. Various attempts to circumvent these restrictions are documented in internationalization-related hints.

Build the linuxthreads man pages, which are a great reference on the threading API (applicable to NPTL as well):

make -C ../glibc-2.3.4-20040701/linuxthreads/man

Install these pages:

make -C ../glibc-2.3.4-20040701/linuxthreads/man install

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 with networking. The time zone also needs to be set up.

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

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., EST5EDT or Canada/Eastern). Then create the /etc/localtime file by running:

cp --remove-destination /usr/share/zoneinfo/[xxx] \
    /etc/localtime

Replace [xxx] with the name of the time zone that the tzselect provided (e.g., Canada/Eastern).

The meaning of the cp option:

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

The Binutils package contains a linker, an assembler, and other tools for handling object files.

This package is known to have issues when its default optimization flags (including the -march and -mcpu options) are changed. If any environment variables that override default optimizations have been defined, such as CFLAGS and CXXFLAGS, unset them when building Binutils.

Verify that the PTYs are working properly inside the chroot environment. Check that everything is set up correctly by performing a simple test:

expect -c "spawn ls"

If the following message shows up, the chroot environment is not set up for proper PTY operation:

The system has no more ptys.  
Ask your system administrator to create more.

This issue needs to be resolved before running the test suites for Binutils and GCC.

The Binutils documentation recommends building Binutils outside of the source directory in a dedicated build directory:

mkdir ../binutils-build
cd ../binutils-build

Prepare Binutils for compilation:

../binutils-2.15.91.0.2/configure --prefix=/usr \
    --enable-shared

Compile the package:

make tooldir=/usr

Normally, the tooldir (the directory where the executables will ultimately be located) is set to $(exec_prefix)/$(target_alias), which expands into /usr/i686-pc-linux-gnu/usr/i686-pc- linux-gnu. Because this is a custom system, this target-specific directory in /usr is not required. This setup would be used if the system was used to cross-compile (for example, compiling a package on an Intel machine that generates code that can be executed on PowerPC machines).

Important

The test suite for Binutils in this section is considered critical. Do not skip it under any circumstances.

Test the results:

make check

Install the package:

make tooldir=/usr install

Install the libiberty header file that is needed by some packages:

cp ../binutils-2.15.91.0.2/include/libiberty.h /usr/include

The GCC package contains the GNU compiler collection, which includes the C and C++ compilers.

This package is known to have issues when its default optimization flags (including the -march and -mcpu options) are changed. If any environment variables that override default optimizations have been defined, such as CFLAGS and CXXFLAGS, unset them when building GCC.

Unpack both the gcc-core and the gcc-g++ tarballs—they will unpack into the same directory. Likewise, extract the gcc-testsuite package. The full GCC package contains additional compilers. Instructions for building these can be found at http://www.linuxfromscratch.org/blfs/view/svn/general/gcc.html.

Apply only the No-Fixincludes patch (not the Specs patch) also used in the previous chapter:

patch -Np1 -i ../gcc-3.4.1-no_fixincludes-1.patch

GCC fails to compile some packages outside of a base Linux From Scratch install (e.g., Mozilla and kdegraphics) when used in conjunction with newer versions of Binutils. Apply the following patch to fix this issue:

patch -Np1 -i ../gcc-3.4.1-linkonce-1.patch

Apply a sed substitution that will suppress the installation of libiberty.a. The version of libiberty.a provided by Binutils will be used instead:

sed -i 's/install_to_$(INSTALL_DEST) //' libiberty/Makefile.in

The GCC documentation recommends building GCC outside of the source directory in a dedicated build directory:

mkdir ../gcc-build
cd ../gcc-build

Prepare GCC for compilation:

../gcc-3.4.1/configure --prefix=/usr \
    --libexecdir=/usr/lib --enable-shared \
    --enable-threads=posix --enable-__cxa_atexit \
    --enable-clocale=gnu --enable-languages=c,c++

Compile the package:

make

Important

In this section, the test suite for GCC is considered critical. Do not skip it under any circumstance.

Test the results, but do not stop at errors:

make -k check

Some of the errors are known issues and were noted in the previous chapter. The test suite notes from the section called “GCC-3.4.1 - Pass 2” are still relevant here. Be sure to refer back to them as necessary.

Install the package:

make install

Some packages expect the C PreProcessor to be installed in the /lib directory. To support those packages, create this symlink:

ln -s ../usr/bin/cpp /lib

Many packages use the name cc to call the C compiler. To satisfy those packages, create a symlink:

ln -s gcc /usr/bin/cc

Note

At this point, it is strongly recommended to repeat the sanity check performed earlier in this chapter. Refer back to the section called “Re-adjusting the Toolchain” and repeat the check. If the results are in error, then the most likely reason is that the GCC Specs patch from Chapter 5 was erroneously applied here.

The Coreutils package contains utilities for showing and setting the basic system characteristics.

A known issue with the uname program from this package is that the -p switch always returns unknown. The following patch fixes this behavior for Intel architectures:

patch -Np1 -i ../coreutils-5.2.1-uname-2.patch

Prevent Coreutils from installing binaries that will be later be installed by other packages:

patch -Np1 -i \
    ../coreutils-5.2.1-suppress_uptime_kill_su-1.patch

Now prepare Coreutils for compilation:

DEFAULT_POSIX2_VERSION=199209 ./configure --prefix=/usr

Compile the package:

make

The test suite of Coreutils makes several assumptions about the presence of files and users that are not valid this early in the LFS build. Therefore, additional items need to be set up before running the tests. Skip down to “Install the package” if not running the test suite.

Create two dummy groups and a dummy user name:

echo "dummy1:x:1000:" >> /etc/group
echo "dummy2:x:1001:dummy" >> /etc/group
echo "dummy:x:1000:1000:::/bin/bash" >> /etc/passwd

Now the test suite is ready to be run. First, run the tests that are meant to be run as user root:

make NON_ROOT_USERNAME=dummy check-root

Then run the remainder of the tests as the dummy user:

src/su dummy -c "make RUN_EXPENSIVE_TESTS=yes check"

When testing is complete, remove the dummy user and groups:

sed -i '/dummy/d' /etc/passwd /etc/group

Install the package:

make install

Move programs to the proper locations:

mv /usr/bin/{[,basename,cat,chgrp,chmod,chown,cp,dd,df} /bin
mv /usr/bin/{date,echo,false,head,hostname,install,ln} /bin
mv /usr/bin/{ls,mkdir,mknod,mv,pwd,rm,rmdir,sync} /bin
mv /usr/bin/{sleep,stty,test,touch,true,uname} /bin
mv /usr/bin/chroot /usr/sbin

Finally, create a symlink to be FHS-compliant:

ln -s ../../bin/install /usr/bin

The Zlib package contains compression and un-compression routines used by some programs.

The following patch fixes a Denial of Service vulnerability in the Zlib compression library:

patch -Np1 -i ../zlib-1.2.1-security-1.patch

Note

Zlib is known to build its shared library incorrectly if CFLAGS is specified in the environment. If using a specified CFLAGS variable, be sure to add the -fPIC directive to the CFLAGS variable for the duration of the configure command below, then remove it afterwards.

Prepare Zlib for compilation:

./configure --prefix=/usr --shared

Compile the package:

make

To test the results, issue: make check.

Install the shared library:

make install

Build the static library:

make clean
./configure --prefix=/usr
make

To test the results again, issue: make check.

Install the static library:

make install

Fix the permissions on the static library:

chmod 644 /usr/lib/libz.a

It is good policy and common practice to place important libraries into the /lib directory. This is most important in scenarios where /usr is on a separate partition. Essentially, the run-time components of any libraries that are used by programs in /bin or /sbin should reside in /lib so that they are on the root partition and available in the event of /usr being inaccessible.

For the above reason, move the run-time components of the shared Zlib into /lib:

mv /usr/lib/libz.so.* /lib

Fix the /usr/lib/libz.so symlink:

ln -sf ../../lib/libz.so.1 /usr/lib/libz.so

The Mktemp package contains programs used to create secure temporary files in shell scripts.

Many scripts still use the deprecated tempfile program, which has functionality similar to mktemp. Patch Mktemp to include a tempfile wrapper:

patch -Np1 -i ../mktemp-1.5-add_tempfile-1.patch

Prepare Mktemp for compilation:

./configure --prefix=/usr --with-libc

The meaning of the configure option:

Compile the package:

make

Install the package:

make install
make install-tempfile

The Iana-Etc package provides data for network services and protocols.

Parse the data:

make

Install the package:

make install

The Findutils package contains programs to find files. Processes 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=/usr --libexecdir=/usr/lib/locate \
    --localstatedir=/var/lib/locate

The localstatedir directive above changes the location of the locate database to be in /var/lib/locate, which is FHS-compliant.

Compile the package:

make

To test the results, issue: make check.

Install the package:

make install

The Gawk package contains programs for manipulating text files.

Prepare Gawk for compilation:

./configure --prefix=/usr --libexecdir=/usr/lib

Compile the package:

make

To test the results, issue: make check.

Install the package:

make install

The Ncurses package contains libraries for terminal-independent handling of character screens.

Prepare Ncurses for compilation:

./configure --prefix=/usr --with-shared --without-debug

Compile the package:

make

This package does not come with a test suite.

Install the package:

make install

Give the Ncurses libraries execute permissions:

chmod 755 /usr/lib/*.5.4

Fix a library that should not be executable:

chmod 644 /usr/lib/libncurses++.a

Move the libraries to the /lib directory, where they are expected to reside:

mv /usr/lib/libncurses.so.5* /lib

Because the libraries have been moved, a few symlinks are pointing to non-existent files. Recreate those symlinks:

ln -sf ../../lib/libncurses.so.5 /usr/lib/libncurses.so
ln -sf libncurses.so /usr/lib/libcurses.so

The Readline package contains the Readline command-line library.

The following patch fixes a problem where Readline sometimes only shows 33 characters on a line and then wraps to the next line.

patch -Np1 -i ../readline-5.0-display_wrap-1.patch

Prepare Readline for compilation:

./configure --prefix=/usr

Compile the package:

make SHLIB_XLDFLAGS=-lncurses

The meaning of the make option:

Install the package:

make install

Give Readline's dynamic libraries more appropriate permissions:

chmod 755 /usr/lib/*.5.0

Move the dynamic libraries to a more appropriate location:

mv /usr/lib/lib{readline,history}.so.5* /lib

Because the libraries have been moved, a few symlinks are now pointing to non-existent files. Recreate those symlinks:

ln -sf ../../lib/libhistory.so.5 /usr/lib/libhistory.so
ln -sf ../../lib/libreadline.so.5 /usr/lib/libreadline.so

The Vim package contains a powerful text editor.

Tip: Alternatives to Vim

If you prefer another editor—such as Emacs, Joe, or Nano—please refer to http://www.linuxfromscratch.org/blfs/view/svn/postlfs/editors.html for suggested installation instructions.

First, unpack both vim-6.3.tar.bz2 and (optionally) vim-6.3-lang.tar.gz archives into the same directory. Then, change the default locations of the vimrc and gvimrc configuration files to /etc:

echo '#define SYS_VIMRC_FILE "/etc/vimrc"' >> src/feature.h
echo '#define SYS_GVIMRC_FILE "/etc/gvimrc"' >> src/feature.h

Prepare Vim for compilation:

./configure --prefix=/usr --enable-multibyte

The optional but highly recommended --enable-multibyte switch includes support for editing files in multibyte character encodings into vim. This is needed if using a locale with a multibyte character set. This switch is also helpful to be able to edit text files initially created in Linux distributions like Fedora Core that use UTF-8 as a default character set.

Compile the package:

make

To test the results, issue: make test. However, this test suite outputs a lot of chaotic characters to the screen, which can cause issues with the settings of the current terminal. Therefore, running the test suite here is optional.

Install the package:

make install

Many users are used to using vi instead of vim. To allow execution of vim when users habitually enter vi, create a symlink:

ln -s vim /usr/bin/vi

If the X Window System is going to be installed on the LFS system, it may be necessary to recompile Vim after installing X. Vim comes with a GUI version of the editor that requires X and some additional libraries to be installed. For more information on this process, refer to the Vim documentation and the Vim installation page in the BLFS book at http://www.linuxfromscratch.org/blfs/view/svn/postlfs/editors.html#postlfs-editors-vim.

By default, vim runs in vi-incompatible mode. This may be new to users who have used other editors in the past. The “nocompatible” setting is included below to highlight the fact that a new behavior is being used. It also reminds those who would change to “compatible” mode that it should appear first. This is necessary because it changes other settings, and overrides must come after this setting. Create a default vim configuration file by running the following:

cat > /etc/vimrc << "EOF"
" Begin /etc/vimrc

set nocompatible
set backspace=2
syntax on
if (&term == "iterm") || (&term == "putty")
  set background=dark
endif

" End /etc/vimrc
EOF

The set nocompatible makes vim behave in a more useful way (the default) than the vi-compatible manner. Remove the “no” to keep the old vi behavior. The set backspace=2 allows backspacing over line breaks, autoindents, and the start of insert. The syntax on enables vim's syntax highlighting. Finally, the if statement with the set background=dark corrects vim's guess about the background color of some terminal emulators. This gives the highlighting a better color scheme for use on the black background of these programs.

Documentation for other available options can be obtained by running the following command:

vim -c ':options'

The M4 package contains a macro processor.

Prepare M4 for compilation:

./configure --prefix=/usr

Compile the package:

make

To test the results, issue: make check.

Install the package:

make install