From f904a8703f23be88ea24ba23e7564b30d1db2aec Mon Sep 17 00:00:00 2001 From: Ian Molton Date: Tue, 1 Jun 2004 21:43:10 +0000 Subject: Touched up the grammar. git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@3736 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689 --- chapter05/adjusting.xml | 66 ++++++++++++++++++++++++------------------------- 1 file changed, 32 insertions(+), 34 deletions(-) (limited to 'chapter05/adjusting.xml') diff --git a/chapter05/adjusting.xml b/chapter05/adjusting.xml index 468241652..ea14302fa 100644 --- a/chapter05/adjusting.xml +++ b/chapter05/adjusting.xml @@ -7,14 +7,16 @@ Adjusting the toolchain -Now that the temporary C libraries have been installed, we want all -the tools compiled in the rest of this chapter to be linked against these -libraries. To accomplish this, we need to adjust the linker and the compiler's -specs file. Some people would say that it is black magic juju +Now that the temporary C libraries have been installed, all +the tools compiled in the rest of this chapter should be linked against these +libraries. In order to accomplish this the linker, and the compiler's +specs file, need to be adjsted. + + Some people would say that there is black magic juju below this line, but it is really very simple. -First install the adjusted linker (adjusted at the end of the first pass -of Binutils) by running the following command from within +First the adjusted linker is installed (adjusted at the end of the first pass +of Binutils), by running the following command from within the binutils-build directory: make -C ld install @@ -22,19 +24,18 @@ the binutils-build directory: From this point onwards everything will link only against the libraries in /tools/lib. -If you somehow missed the earlier warning to retain the Binutils -source and build directories from the first pass or otherwise accidentally -deleted them or just don't have access to them, don't worry, all is not lost. -Just ignore the above command. The result is a small chance of the subsequent +If you missed the earlier warning to retain the Binutils +source and build directories from the first pass, dont worry - all is not lost. +Just ignore the above command. This results in a small chance of the subsequent testing programs linking against libraries on the host. This is not ideal, but -it's not a major problem. The situation is corrected when we install the -second pass of Binutils a bit further on. +it's not a major problem. The situation is corrected when the second pass of +Binutils is installed later on. -Now that the adjusted linker is installed, you have to -remove the Binutils build and source directories. +Now that the adjusted linker is installed, the Binutils build and source +direcotries should be removed. -The next 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: +The next task is to amend our GCC specs file so that it points +to the new dynamic linker. A simple sed script will accomplish this: @@ -44,11 +45,9 @@ sed -e 's@ /lib/ld-linux.so.2@ /tools/lib/ld-linux.so.2@g' \ mv -f tempspecfile $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 the -occurrence of /lib/ld-linux.so.2 with -/tools/lib/ld-linux.so.2. Be sure to visually inspect the specs -file to verify the intended change was actually made. +It is recommended that the above command be cut-and-pasted in order to ensure correctness - Alternatively the specs file can be edited by hand. This is done simply by replacing every occurrence of /lib/ld-linux.so.2 with /tools/lib/ld-linux.so.2. + + Be sure to visually inspect the specs file in order to verify the intended changes have been mande. If you are working on a platform where the name of the dynamic linker is something other than ld-linux.so.2, you @@ -58,45 +57,44 @@ name of your platform's dynamic linker in the above commands. Refer back to 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 -because of GCC's fixincludes process which runs as part of the -GCC build. We'll explain more about this further on in this chapter. For now, -run the following commands to eliminate this possibility: +as a result of of GCC's fixincludes process which runs as part +of the GCC build. We'll explain more about this further on in this chapter. +Run the following commands to eliminate this possibility: rm -f /tools/lib/gcc/*/*/include/{pthread.h,bits/sigthread.h} It is imperative at this point to stop and ensure that the basic functions (compiling and linking) of the new toolchain are working as expected. -For this we are going to perform a simple sanity check: +To perform a simple sanity check run the following commands: echo 'main(){}' > dummy.c cc dummy.c readelf -l a.out | grep ': /tools' If everything is working correctly, there should be no errors, and the -output of the last command will be (allowing for platform specific differences -in dynamic linker name): +output of the last command will be of the form:
[Requesting program interpreter: /tools/lib/ld-linux.so.2]
Note especially that /tools/lib appears as the prefix of our dynamic linker. -If you did not receive the output -as shown above, or received no output at all, then something is seriously wrong. -You will need to investigate and retrace your steps to find out where the +If the output is not +as shown above, or there was no output at all, then something is seriously +wrong. You will need to investigate and retrace your steps to find out where the problem is and correct it. There is no point in continuing until this is done. -First, redo the sanity check using gcc instead of -cc. If this works it means the +First, perform the sanity check again, using gcc instead of +cc. If this works then the /tools/bin/cc symlink is missing. Revisit - and fix the symlink. Second, ensure your PATH + and install the symlink. Second, ensure your PATH 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 -ensuring to cut-and-paste the commands as was recommended. +being careful to cut-and-paste the commands. Once you are satisfied that all is well, clean up the test files: -- cgit v1.2.3-54-g00ecf