From c6b5ddb7a6bd11d84c183cd3c3fd3c507f797978 Mon Sep 17 00:00:00 2001 From: Alex Gronenwoud Date: Sun, 7 Mar 2004 12:09:31 +0000 Subject: Shifting chapter contents, and moving preparational sections of chapter 5 to a separate chapter. git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@3284 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689 --- chapter05/chapter05.xml | 208 ++++-------------------------------------------- 1 file changed, 15 insertions(+), 193 deletions(-) (limited to 'chapter05') diff --git a/chapter05/chapter05.xml b/chapter05/chapter05.xml index 9217c1831..f8724b46b 100644 --- a/chapter05/chapter05.xml +++ b/chapter05/chapter05.xml @@ -23,9 +23,9 @@ Since the packages compiled here are merely temporary, we don't want them to pollute the soon-to-be LFS system. Before issuing the build instructions for a package you are expected to -have already unpacked it as user lfs (explained shortly), -and to have performed a cd into the created directory. -The build instructions assume that you are using the bash +have already unpacked it as user lfs, and to have +performed a cd into the created directory. The build +instructions assume that you are using the bash shell. Several of the packages are patched before compilation, but only when @@ -50,21 +50,12 @@ reinstalled further on. Only for three packages you will need to keep the source and build directories around for a while, so their contents can be used by later commands. Do not miss the reminders. -Now first check that your LFS environment variable is set up -properly: - -echo $LFS - -Make sure the output shows the path to your LFS partition's mount -point, which is /mnt/lfs if you -followed our example. - - -Toolchain technical notes - + +Technical notes + This section attempts to explain some of the rationale and technical details behind the overall build method. It's not essential that you understand @@ -217,8 +208,12 @@ we mentioned above. Once this Glibc is installed into the toolchain defaults, then proceed for real in building the rest of the target LFS system. - + + + + Notes on static linking + Most programs have to perform, beside their specific task, many rather common and sometimes trivial operations. These include allocating memory, @@ -257,179 +252,6 @@ independently of the host system. However, it's worth noting that an overall successful LFS build can still be achieved when the first two packages are built dynamically. - - - - - - -Creating the $LFS/tools directory - - -All programs compiled in this chapter will be installed under $LFS/tools to keep them separate from the -programs compiled in the next chapter. The programs compiled here are only -temporary tools and won't be a part of the final LFS system and by keeping them -in a separate directory, we can later easily throw them away. - -Later on you might wish to search through the binaries of your system to -see what files they make use of or link against. To make this searching easier -you may want to choose a unique name for the directory in which the temporary -tools are stored. Instead of the simple "tools" you could use something like -"tools-for-lfs". However, you'll need to be careful to adjust all references to -"tools" throughout the book -- including those in any patches, notably the -GCC Specs Patch. - -Create the required directory by running the following: - -mkdir $LFS/tools - -The next step is to create a /tools symlink on -your host system. It will point to the directory we just created on the LFS -partition: - -ln -s $LFS/tools / - -The above command is correct. The ln command -has a few syntactic variations, so be sure to check the info page before -reporting what you may think is an error. - -The created symlink enables us to compile our toolchain so that it always -refers to /tools, meaning that the compiler, assembler -and linker will work both in this chapter (when we are still using some tools -from the host) and in the next (when we are chrooted to -the LFS partition). - - - - - -Adding the user lfs - - -When logged in as root, making a single mistake -can damage or even wreck your system. Therefore we recommend that you -build the packages in this chapter as an unprivileged user. You could -of course use your own user name, but to make it easier to set up a clean -work environment we'll create a new user lfs and -use this one during the installation process. As root, -issue the following command to add the new user: - -useradd -s /bin/bash -m -k /dev/null lfs - -The meaning of the switches: - - --s /bin/bash: This makes -bash the default shell for user -lfs. - --m -k /dev/null: These create a home -directory for lfs, while preventing the files from a -possible /etc/skel being copied into it. - - -If you want to be able to log in as lfs, then give -this new user a password: - -passwd lfs - -Now grant this new user lfs full access to -$LFS/tools by giving it ownership -of the directory: - -chown lfs $LFS/tools - -If you made a separate working directory as suggested, give user -lfs ownership of this directory too: - -chown lfs $LFS/sources - -Next, login as user lfs. This can be done via a -virtual console, through a display manager, or with the following substitute -user command: - -su - lfs - -The "-" instructs su to start a -login shell. - - - - - -Setting up the environment - - -We're going to 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 - -Normally, when you log on as user lfs, -the initial shell is a login shell which reads the -/etc/profile of your host (probably containing some -settings of environment variables) and then .bash_profile. -The exec env -i ... /bin/bash command in the latter 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 our -build environment. The technique used here is a little strange, but it achieves -the goal of enforcing a clean environment. - -The new instance of the shell is a non-login shell, -which doesn't read the /etc/profile or -.bash_profile files, but reads the -.bashrc file instead. Create this latter file now: - -cat > ~/.bashrc << "EOF" -set +h -umask 022 -LFS=/mnt/lfs -LC_ALL=POSIX -PATH=/tools/bin:/bin:/usr/bin -export LFS LC_ALL PATH -EOF - -The set +h command turns off -bash's hash function. Normally hashing is a useful -feature: bash uses a hash table to remember the -full pathnames of executable files to avoid searching the PATH time and time -again to find the same executable. However, we'd like the new tools to be -used as soon as they are installed. By switching off the hash function, our -"interactive" commands (make, -patch, sed, -cp and so forth) will always use -the newest available version during the build process. - -Setting the user file-creation mask to 022 ensures that newly created -files and directories are only writable for their owner, but readable and -executable for anyone. - -The LFS variable should of course be set to the mount point you -chose. - -The LC_ALL variable controls the localization of certain programs, -making their messages follow the conventions of a specified country. If your -host system uses a version of Glibc older than 2.2.4, -having LC_ALL set to something other than "POSIX" or "C" during this chapter -may cause trouble if you exit the chroot environment and wish to return later. -By setting LC_ALL to "POSIX" (or "C", the two are equivalent) we ensure that -everything will work as expected in the chroot environment. - -We prepend /tools/bin to the standard PATH so -that, as we move along through this chapter, the tools we build will get used -during the rest of the building process. - -Finally, to have our environment fully prepared for building the -temporary tools, source the just-created profile: - -source ~/.bash_profile - @@ -490,7 +312,7 @@ made. linker is something other than ld-linux.so.2, you must substitute ld-linux.so.2 with the name of your platform's dynamic linker in the above commands. Refer back to - if necessary. + if necessary. Lastly, there is a possibility that some include files from the host system have found their way into GCC's private include dir. This can happen @@ -531,9 +353,9 @@ First, redo the sanity check using gcc instead of is correct. You can check this by running echo $PATH and verifying that /tools/bin is at the head of the list. If the PATH is wrong it could mean you're not logged in as user -lfs or something went wrong back in -. Third, something may have gone wrong with -the specs file amendment above. In this case redo the specs file amendment +lfs or something went wrong back in . Third, something may have gone wrong +with the specs file amendment above. In this case redo the specs file amendment ensuring to cut-and-paste the commands as was recommended. Once you are satisfied that all is well, clean up the test files: -- cgit v1.2.3-54-g00ecf