From 66e432588705fb9a93210428be3ab4d1ab711792 Mon Sep 17 00:00:00 2001 From: Gerard Beekmans Date: Tue, 3 Jun 2003 22:25:25 +0000 Subject: Applied Alex' "apapting-the-text.patch" patch git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@2639 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689 --- chapter05/adding-user.xml | 24 +++++----- chapter05/binutils-pass1-inst.xml | 38 ++++++++------- chapter05/creatingstage1dir.xml | 14 +++--- chapter05/gcc-pass1-inst.xml | 97 +++++++++++++++------------------------ chapter05/glibc-inst.xml | 40 +++++++++------- chapter05/introduction.xml | 15 ++++-- chapter05/kernelheaders-inst.xml | 28 +++-------- chapter05/lockingglibc.xml | 26 ++++++++++- chapter05/setting-environment.xml | 48 +++++++++---------- chapter05/whystatic.xml | 25 ++++------ 10 files changed, 178 insertions(+), 177 deletions(-) (limited to 'chapter05') diff --git a/chapter05/adding-user.xml b/chapter05/adding-user.xml index 131368503..8e4881815 100644 --- a/chapter05/adding-user.xml +++ b/chapter05/adding-user.xml @@ -2,24 +2,26 @@ Adding the user lfs -If you are logged in as root during Chapter 5, -your host system can be damaged by a single mistake. We recommend that -you build the packages in Chapter 5 as an unprivileged user. You could use -your own user name, but to ensure a clean build environment, we'll create a -new user: lfs. As root, issue -the following commands to add the new user: +When logged in as root, making a single mistake +can damage or even wreck your system. Therefore we recommend that you +build the packages in this chapter as an unprivileged user. You could +of course use your own user name, but to make it easier to set up a clean +work environment we'll create a new user lfs and +use this one during the installation process. As root, +issue the following commands to add the new user: useradd -s /bin/bash -m lfs passwd lfs -In order to grant ownership of the $LFS/stage1 -directory to the user lfs, issue the command: +Now grant this new user lfs full access to +$LFS/stage1 by giving it ownership +of the directory: chown lfs $LFS/stage1 -Next, login as user lfs. This can be accomplished -via a virtual console, display manager or with the substitute user -command: +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 diff --git a/chapter05/binutils-pass1-inst.xml b/chapter05/binutils-pass1-inst.xml index 13f478daa..2adbdf700 100644 --- a/chapter05/binutils-pass1-inst.xml +++ b/chapter05/binutils-pass1-inst.xml @@ -3,11 +3,15 @@ Installation of Binutils +It is important that Binutils be the first package to get compiled, +because both Glibc and GCC perform various tests on the available linker and +assembler to determine which of their own features to enable. + This package is known to behave badly when you have changed its default optimization flags (including the -march and -mcpu options). Therefore, if you have defined any environment variables that override default optimizations, such as CFLAGS and CXXFLAGS, we recommend unsetting or -modifying them when building binutils. +modifying them when building Binutils. It is recommended by the Binutils installation documentation to build Binutils outside of the source directory in a dedicated directory: @@ -20,13 +24,16 @@ cd ../binutils-build ../binutils-&binutils-version;/configure \     --prefix=/stage1 --disable-nls -The meaning of the (new) configure switches are: +The meaning of the configure switches is: ---disable-nls: This option disables -internationalization (also known as i18n). We don't need this for our -static programs and nls often causes problems when you're linking -statically. +--prefix=/stage1: This tells the +configure script to prepare to install the Binutils programs in the +/stage1 directory. +--disable-nls: This disables +internationalization (a word often shortened to i18n). We don't need this +for our static programs and nls often causes problems +when linking statically. Continue with compiling the package: @@ -36,24 +43,23 @@ statically. The meaning of the make option is: -LDFLAGS="-all-static": This is -how we tell Binutils that all programs should be statically linked. Setting -the LDFLAGS variable is the common way of specifying we -want a static link to take place, however, its value and the way it is set -is not always the same. You'll see with the remaining packages that there -are different ways of setting up the LDFLAGS -variable. +LDFLAGS="-all-static": This tells +the linker that all the Binutils programs should be linked +statically. -And finish off installing the package: +And install the package: make install +Now already prepare the linker for the "locking in" of +glibc later on: + make -C ld clean make -C ld LIB_PATH=/stage1/lib -Do not remove the binutils-* directories. We need them again -later on in this chapter. +Do not yet remove the binutils-* directories. +We will need them again a bit further on in this chapter. diff --git a/chapter05/creatingstage1dir.xml b/chapter05/creatingstage1dir.xml index 0a34be4eb..7e4b733a9 100644 --- a/chapter05/creatingstage1dir.xml +++ b/chapter05/creatingstage1dir.xml @@ -11,15 +11,17 @@ required directory by running the following: mkdir $LFS/stage1 -The next step is to create a "/stage1" symlink on the host system. It -will point to the directory we just created on the LFS partition: +The next step is to create a /stage1 symlink on +your host system. It will point to the directory we just created on the LFS +partition: ln -s $LFS/stage1 / -This ensures our toolchain will look in the same place (i.e. /stage1) -in both Chapters 5 and 6 (when we are inside the chroot). This is an -important concept to grasp. Don't worry if it's not clear right now, all -will make sense once we get into Chapter 6. +This symlink enables us to compile our toolchain so that it always +refers to /stage1, meaning that the compiler, assembler +and linker will work both in this chapter (when we are still rummaging around +on the host) and in the next (when we are chrooted to +the LFS partition). diff --git a/chapter05/gcc-pass1-inst.xml b/chapter05/gcc-pass1-inst.xml index b290d05f2..e9a649776 100644 --- a/chapter05/gcc-pass1-inst.xml +++ b/chapter05/gcc-pass1-inst.xml @@ -3,7 +3,7 @@ Installation of GCC -We won't be needing a C++ compiler until Chapter 6. So, only +We won't be needing a C++ compiler until the next chapter. So, only the gcc-core tarball needs to be unpacked at this time. This package is known to behave badly when you have changed its @@ -28,79 +28,58 @@ cd ../gcc-build     --disable-nls --enable-shared \     --enable-languages=c -The meaning of the configure options are: +The meaning of the new configure options is: ---prefix=/static: This is NOT a -typo. GCC hard codes some paths while compiling and so we need to pass -/static as the prefix during the -configure stage. We will pass the real installation prefix ($LFS/static) during the installation -stage later on. - ---disable-shared: This prevents the -build of dynamic libraries. They are useless to us at the moment. We'll -create them when we reinstall GCC in chapter 6. - ---with-as=$LFS/static/bin/as and ---with-ld=$LFS/static/bin/ld: GCC can be miscompiled if your -host distribution's Binutils package is quite old. We need a good working -static GCC until we reinstall GCC later in chapter 6. So by using -as and ld from the Binutils -package we compiled earlier in this chapter we ensure that GCC will work -correctly. +--with-local-prefix=/stage1: The +purpose of this switch is to remove /usr/local/include +from gcc's include search path. This is not absolutely +essential, but we want to try and minimize the influence from the host system, +so this seems a logical thing to do. + +--enable-shared: This switch may +seem counter-intuitive at first. But using it allows the building of +libgcc_s.so.1 and libgcc_eh.a, and +having libgcc_eh.a available ensures that the configure +script for Glibc (the next package we compile) produces the proper results. +Please note that the gcc binaries will still be linked +statically, as this is controlled by the -static +value of BOOT_LDFLAGS further on. + +--enable-languages=c: This will build +only the C compiler from the GCC package. We won't be needing anything else +during this chapter. Continue with compiling the package: make BOOT_LDFLAGS="-static" bootstrap -The meaning of the make options are: +The meaning of the make parameters is: -BOOT_LDFLAGS="-static": This is -GCC's equivalent to make LDFLAGS="-static" as we use with other packages to -compile them statically. - -bootstrap: The -bootstrap target doesn't just compile GCC, but it -compiles GCC a second time. It uses the first compiled programs to compile -itself a second and third time to make sure the compiler was compiled properly -and can compile itself properly. +BOOT_LDFLAGS="-static": This tells +GCC to link its programs statically. + +bootstrap: This target doesn't just +compile GCC, but compiles it several times. It uses the programs compiled in +a first round to compile itself a second time, and then again a third time. +It then compares these second and third compiles to make sure it can +reproduce itself flawlessly, which most probably means that it was +compiled correctly. -And finish off installing the package: +And install the package: make install -The meaning of the make option is: - - -install-no-fixedincludes: This prevents -the fixincludes script from running. Preventing this is necessary because -under normal circumstances the GCC installation will run the fixincludes -script which scans your system for header files that need to be fixed. It -might find that the Glibc header files of your host system need to be fixed. -If so, it will fix them and put them in -$LFS/static/lib/gcc-lib/i686-pc-linux-gnu/3.2. Later on -in chapter 6 you will install Glibc which will put its header files in -/usr/include. Next you will install other programs that -use the Glibc headers and GCC will look in -/static/lib/gcc-lib before looking in -/usr/include, with the result of finding and using the -fixed Glibc header files from your host distribution, which are probably -incompatible with the Glibc version actually used on the LFS -system. - - -As the finishing touch we'll create the $LFS/static/bin/cc symlink. A lot of programs -and scripts try to run cc instead of -gcc This is to keep programs generic and usable on -all kinds of Unix systems. Not everybody has GNU CC installed. Just running -cc (C Compiler) leaves the user free to decide which -C compiler to install. The symlink will point to the system's default -compiler. +As a finishing touch we'll create the /stage1/bin/cc symlink. Many programs and +scripts run cc instead of gcc, +a thing meant to keep programs generic and therefore usable on all kinds of +Unix systems. Not everybody has the GNU C compiler installed. Simply running +cc leaves the system administrator free to decide what +C compiler to install, as long as there's a symlink pointing to it: ln -sf gcc /stage1/bin/cc diff --git a/chapter05/glibc-inst.xml b/chapter05/glibc-inst.xml index 499b2ae02..b8e84de43 100644 --- a/chapter05/glibc-inst.xml +++ b/chapter05/glibc-inst.xml @@ -15,11 +15,11 @@ default optimizations, such as CFLAGS and CXXFLAGS, we recommend unsetting them when building Glibc. Basically, compiling Glibc in any other way than the book suggests -is putting your system at a very high risk. +is putting the stability of your system at risk. Though it is a harmless message, the install stage of Glibc will -complain about the presence of /etc/ld.so.conf (or lack thereof). Fix -this annoying little error: +complain about the absence of /etc/ld.so.conf. +Fix this annoying little error with: mkdir /stage1/etc touch /stage1/etc/ld.so.conf @@ -38,7 +38,7 @@ cd ../glibc-build     --with-binutils=/stage1/bin \     --without-gd -The meaning of the configure options are: +The meaning of the new configure options is: --disable-profile: This disables the @@ -46,11 +46,18 @@ building of the libraries with profiling information. Omit this option if you plan to do profiling. --enable-add-ons: This enables any -add-ons that we installed with Glibc, in our case Linuxthreads. - ---libexecdir=/usr/bin: This will -cause the pt_chown program to be installed in the -/usr/bin directory. +add-ons that were installed with Glibc, in our case Linuxthreads. + +--with-binutils=/stage1/bin and +--with-headers=/stage1/include: Strictly speaking +these switches are not required. But they ensure nothing can go wrong with +regard to what kernel headers and Binutils programs get used during the +Glibc build. + + --without-gd: This switch ensures +that we don't build the memusagestat program, which +strangely enough insists on linking against the host's libraries (libgd, +libpng, libz, and so forth). During this stage you will see the following warning: @@ -76,16 +83,17 @@ would require you to regenerate the binary files. make check make install -The locales (used by Glibc to make your Linux system talk in a different -language) weren't installed when you ran the previous command, so we have to -do that ourselves now: +The locales (used by Glibc to make your Linux system respond in a +different language) weren't installed when you ran the previous command, +so we have to do that ourselves now: make localedata/install-locales -An alternative to running the previous command is to install only those -locales which you need or want. This can be achieved using the localedef -command. Information on this can be found in the INSTALL -file in the glibc-&glibc-version; tree. +An alternative to running the previous command is to install only +those locales which you need or want. This can be achieved by using the +localedef command. Information on this can be +found in the INSTALL file in the +glibc-&glibc-version; tree. diff --git a/chapter05/introduction.xml b/chapter05/introduction.xml index bd0145290..aecb28cfb 100644 --- a/chapter05/introduction.xml +++ b/chapter05/introduction.xml @@ -6,16 +6,23 @@ Linux system. This system will contain just enough tools to be able to start constructing the final LFS system in the next chapter. +The building of this minimal system is done in two steps: first we +build a brand-new and host-independent toolchain (compiler, assembler, +linker and libraries), and then use this to build all the other essential +tools. + The files compiled in this chapter will be installed under the -$LFS/static directory, +$LFS/stage1 directory, to keep them separate from the files installed in the next chapter. Since the packages compiled here are merely temporary, we don't want them to pollute the soon-to-be LFS system. The key to learning what makes a Linux system work is to know -exactly what each package is used for, and why the user or the system -needs it. For this purpose a short description of the content of each -package is given right after the installation instructions. +what each package is used for, why the user or the system needs it. +For this purpose a short summary of the content of each package is given +before the actual installation instructions. For a short description of +each program in a package, please refer to the corresponding section in +. Several of the packages are patched before compilation, but only when the patch is needed to circumvent a problem. Often the patch is needed in diff --git a/chapter05/kernelheaders-inst.xml b/chapter05/kernelheaders-inst.xml index dac03be82..96f629dd0 100644 --- a/chapter05/kernelheaders-inst.xml +++ b/chapter05/kernelheaders-inst.xml @@ -3,27 +3,11 @@ Installation of the kernel headers -We won't be compiling a new kernel yet -- we'll do that when we have -finished the installation of all the packages. But as some packages need the -kernel header files, we're going to unpack the kernel archive now, set it up -and copy the header files so they can be found by these packages. - -It is important to note that the files in the kernel source directory -are not owned by root. Whenever you unpack a package as -user root (like we do here inside chroot), the files end -up having the user and group IDs of whatever they were on the packager's -computer. This is usually not a -problem for any other package you install because you remove the source -tree after the installation. But the Linux kernel source tree is often kept -around for a long time, so there's a chance that whatever user ID the packager -used will be assigned to somebody on your machine and then that person would -have write access to the kernel source. - -In light of this, you might want to run chown -R 0:0 -on the linux-&kernel-version; directory -to ensure all files are owned by user root. - -Prepare for header installation: +As some packages need to refer to the kernel header files, we're going +to unpack the kernel archive now, set it up, and copy the required files to a +place where gcc can later find them. + +Prepare for the header installation with: make mrproper @@ -41,7 +25,7 @@ symlink: make symlinks -Install the platform specific-header files: +Install the platform-specific header files: mkdir /stage1/include/asm cp include/asm/* /stage1/include/asm diff --git a/chapter05/lockingglibc.xml b/chapter05/lockingglibc.xml index 95d086467..45a4fe5fb 100644 --- a/chapter05/lockingglibc.xml +++ b/chapter05/lockingglibc.xml @@ -5,12 +5,27 @@    -Installation of Binutils +Installation of the linker scripts make -C ld install-data-local -You can remove the binutils-* directories now. +This installs the adjusted linker scripts. Remember they were adjusted +a little while back, at the end of the first pass of Binutils? The linker +scripts now contain no mention of /lib, +/usr/lib or /usr/local/lib. +From this point onwards everything will link only +against the libraries in /stage1/lib. +You can now remove the binutils-* directories. + + + + +Amending GCC's specs file + +The final thing to do is to amend our GCC specs file so that it points +to the new dynamic linker. A simple sed will accomplish this: + SPECFILE=/stage1/lib/gcc-lib/*/*/specs sed -e 's@/lib/ld.so.1@/stage1/lib/ld.so.1@g' \     -e 's@/lib/ld-linux.so.2@/stage1/lib/ld-linux.so.2@g' \ @@ -18,6 +33,13 @@ sed -e 's@/lib/ld.so.1@/stage1/lib/ld.so.1@g' \ mv XX $SPECFILE unset SPECFILE +We recommend that you cut-and-paste the above rather than try and type +it all in. Or you can edit the specs file by hand if you want to: just replace +"/lib/ld-linux.so.2" with "/stage1/lib/ld-linux.so.2". + +This completes the installation of the self-contained toolchain, which +can now be used to build the rest of the temporary tools. + diff --git a/chapter05/setting-environment.xml b/chapter05/setting-environment.xml index 45675ea76..20d8f7ea1 100644 --- a/chapter05/setting-environment.xml +++ b/chapter05/setting-environment.xml @@ -1,6 +1,6 @@ Setting up the environment - + While logged in as user lfs, issue the following commands to set up a good work environment: @@ -13,41 +13,41 @@ LC_ALL=POSIX PATH=/stage1/bin:$PATH export LFS LC_ALL PATH EOF -source ~/.bash_profile -set +h turns off Bash's hash function. Hash -normally is a useful feature where Bash uses a hash table to remember the -full pathnames of executable files to avoid multiple `PATH' searches. -However, we'd like the new tools to become available as soon as they are -installed. By switching off the hash function, our "interactive" commands -(make, patch, sed, cp and so forth) will always use the newest available -during the build process. - -This profile sets the umask to 022, so newly created files and -directories will have the correct permissions. To be more specific, only -the file owner will have write permission to new files and directories. -Other users of the system will be have read permission, and executable -permission to directories. It is advisable to keep this setting throughout -your LFS installation. +source ~/.bash_profile +The set +h command turns off +bash's hash function. Normally hashing is a useful +feature: bash uses a hash table to remember the +full pathnames of executable files to avoid searching the PATH time and time +again to find the same executable. However, we'd like the new tools to be +used as soon as they are installed. By switching off the hash function, our +"interactive" commands (make, +patch, sed, +cp and so forth) will always use +the newest available version during the build process. + +Setting the user file-creation mask to 022 ensures that newly created +files and directories are only writable for their owner, but readable and +executable for anyone. + The LFS variable should of course be set to the mount point you chose. The LC_ALL variable controls the localization of certain programs, making their messages follow the conventions of a specified country. If your host system uses a version of glibc older than 2.2.4, -having LC_ALL set to something other than "C" or "POSIX" during this chapter +having LC_ALL set to something other than "POSIX" or "C" during this chapter may cause trouble if you exit the chroot environment and wish to return later. -By setting LC_ALL to "POSIX" ("C" is an alias for "POSIX") we ensure that +By setting LC_ALL to "POSIX" (or "C", the two are equivalent) we ensure that everything will work as expected in the chroot environment. -LDFLAGS is a variable we set in order to prevent debugging symbols from -being compiled into our static packages. By omitting these symbols during -the linking stage of compilation, we save hard drive space and decrease our -build time. +We prepend /stage1/bin to the standard PATH so +that, as we move along through this chapter, the tools we build will get used +during the rest of the building process. -We are now prepared to begin building the temporary tools which will -support us in later chapters. +Now, after sourcing the just-created profile, we're all set to begin +building the temporary tools that will support us in later chapters. diff --git a/chapter05/whystatic.xml b/chapter05/whystatic.xml index 59b221e55..86a550154 100644 --- a/chapter05/whystatic.xml +++ b/chapter05/whystatic.xml @@ -42,23 +42,14 @@ of the improved function. memory space, disk space, and recompile time. But if dynamic linking saves so much space, why then are we linking -all programs in this chapter statically? The reason is that we won't be -compiling a temporary glibc here. And we avoid doing this -simply to save some time -- around 14 SBUs. Another reason is that the -Glibc version on the LFS system might not be compatible with the Glibc on -the host system. Applications compiled against your host system's Glibc -version may not run properly (or at all) on the LFS system. - -This means that the tools compiled in this chapter will have to be -self-contained, because when later on we chroot to the LFS partition the -GNU library won't be available. That is why we use the --static, --enable-static-link, -and --disable-shared flags throughout this chapter, to -ensure that all executables are statically linked. When we come to the next -chapter, almost the first thing we do is build glibc, the -main set of system libraries. Once this is done, we can link all other programs -dynamically (including the ones installed statically in this chapter) and -take advantage of the space saving opportunities. +the first two packages in this chapter statically? The reason is to make them +independent from the libraries on your host system. And the point in that is +that, if you are pressed for time, you could skip the second passes over GCC +and Binutils, and just use the static versions to compile the rest of this +chapter and the first few packages in the next. As in the next chapter we +will be chrooted to the LFS partition and your host system's Glibc won't be +available, the programs from GCC and Binutils will need to be self-contained, +that is statically linked. -- cgit v1.2.3-54-g00ecf