Adjusting the toolchain

Adjusting the toolchain
Prev	Chapter 5. Constructing a temporary system	Next

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 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 the binutils-build directory:

make -C ld install

From this point onwards everything will link only against the libraries in /tools/lib.

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

Now that the adjusted linker is installed, you have to remove the Binutils build and source directories.

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:

SPECFILE=/tools/lib/gcc-lib/*/*/specs &&
sed -e 's@ /lib/ld-linux.so.2@ /tools/lib/ld-linux.so.2@g' \
    $SPECFILE > tempspecfile &&
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.

	Important
	If you are working on a platform where the name of the dynamic linker is something other than `ld-linux.so.2`, you must replace `ld-linux.so.2` with the name of your platform's dynamic linker in the above commands. Refer back to the section called “Toolchain technical notes” 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 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:

rm -f /tools/lib/gcc-lib/*/*/include/{pthread.h,bits/sigthread.h}

Caution

	Caution
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: `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): [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 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 `/tools/bin/cc` symlink is missing. Revisit the section called “GCC-3.3.3 - Pass 1” and fix 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 the section called “Setting up the environment”. 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: `rm dummy.c a.out`

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:

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

[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 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 /tools/bin/cc symlink is missing. Revisit the section called “GCC-3.3.3 - Pass 1” and fix 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 the section called “Setting up the environment”. 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:

rm dummy.c a.out

Prev	Up	Next
Glibc-2.3.3	Home	Tcl-8.4.6