diff --git a/chapter05/gcc-pass2-inst.xml b/chapter05/gcc-pass2-inst.xml index cde5cb609..7a7e90d38 100644 --- a/chapter05/gcc-pass2-inst.xml +++ b/chapter05/gcc-pass2-inst.xml @@ -24,9 +24,6 @@ are able to resolve the issue. You can consult the LFS Wiki at for more information on how to get PTYs working. -It's worth pointing out that the GCC test suite we run in this -section is considered not as important as the one we run in Chapter 6. - Unpack all three GCC tarballs (-core, -g++, and -testsuite) in one and the same working directory. They will all unfold into a single gcc-&gcc-version;/ subdirectory. diff --git a/chapter05/toolchaintechnotes.xml b/chapter05/toolchaintechnotes.xml index da97ef536..0b19468db 100644 --- a/chapter05/toolchaintechnotes.xml +++ b/chapter05/toolchaintechnotes.xml @@ -38,7 +38,7 @@ something completely different. You should be able to determine the name of your platform's dynamic linker by looking in the /lib directory on your host system. A surefire way is to inspect a random binary from your host system by running: -`readelf -l <name of binary> | grep interpreter` +'readelf -l <name of binary> | grep interpreter' and noting the output. The authoritative reference covering all platforms is in the shlib-versions file in the root of the Glibc source tree. @@ -75,11 +75,11 @@ much time is wasted. the tools in one location are hard linked to the other. An important facet of the linker is its library search order. Detailed information can be obtained from ld by passing it the --verbose -flag. For example: `ld --verbose | grep SEARCH` will +flag. For example: 'ld --verbose | grep SEARCH' will show you the current search paths and their order. You can see what files are actually linked by ld by compiling a dummy program and passing the --verbose switch. For example: -`gcc dummy.c -Wl,--verbose 2>&1 | grep succeeded` +'gcc dummy.c -Wl,--verbose 2>&1 | grep succeeded' will show you all the files successfully opened during the link. The next package installed is GCC and during its run of @@ -93,10 +93,10 @@ that GCC's configure script does not search the $PATH directories to find which tools to use. However, during the actual operation of gcc itself, the same search paths are not necessarily used. You can find out which standard linker gcc will use by running: -`gcc -print-prog-name=ld`. +'gcc -print-prog-name=ld'. Detailed information can be obtained from gcc by passing it the -v flag while compiling a dummy program. For -example: `gcc -v dummy.c` will show you detailed +example: 'gcc -v dummy.c' will show you detailed information about the preprocessor, compilation and assembly stages, including gcc's include search paths and their order. @@ -126,7 +126,7 @@ linker in /tools/lib. This last step is vital to the whole process. As mentioned above, a hard-wired path to a dynamic linker is embedded into every ELF shared executable. You can inspect this by running: -`readelf -l <name of binary> | grep interpreter`. +'readelf -l <name of binary> | grep interpreter'. By amending gcc's specs file, we are ensuring that every program compiled from here through the end of Chapter 5 will use our new dynamic linker in /tools/lib. diff --git a/chapter06/gcc-inst.xml b/chapter06/gcc-inst.xml index ad1b7dbf3..835df60b6 100644 --- a/chapter06/gcc-inst.xml +++ b/chapter06/gcc-inst.xml @@ -70,7 +70,7 @@ compiler. To satisfy those packages, create a symlink: ln -s gcc /usr/bin/cc At this point it is strongly recommended to repeat the sanity check -we performed in the previous chapter. Refer back to +we performed earlier in this chapter. Refer back to and repeat the check. If the results are wrong, then most likely you erroneously applied the GCC Specs patch from Chapter 5. diff --git a/index.xml b/index.xml index 5bb5fbb31..2f10b362a 100644 --- a/index.xml +++ b/index.xml @@ -3,8 +3,8 @@ "/usr/share/docbook/docbookx.dtd" [ - - + +