From a4f63e494b2f26939615cf7e55f51029a763aef4 Mon Sep 17 00:00:00 2001 From: Xi Ruoyao Date: Sun, 27 Feb 2022 13:04:05 +0800 Subject: remove adjusting.xml Now adjusting.xml only serves as a historical reference, and a "snip library" for gcc.xml. Put all relevant content into gcc.xml directly and remove adjusting.xml. If someone needs a historical reference, he can always get adjusting.xml in Git history. --- chapter08/adjusting.xml | 126 ------------------------------------------------ chapter08/gcc.xml | 99 +++++++++++++------------------------ 2 files changed, 33 insertions(+), 192 deletions(-) delete mode 100644 chapter08/adjusting.xml (limited to 'chapter08') diff --git a/chapter08/adjusting.xml b/chapter08/adjusting.xml deleted file mode 100644 index 7d01dcfb6..000000000 --- a/chapter08/adjusting.xml +++ /dev/null @@ -1,126 +0,0 @@ - - - %general-entities; -]> - - - - - Adjusting the Toolchain - - Now that the final C libraries have been installed, it is time to adjust - the toolchain so that it will link any - newly compiled program against these new libraries. - - First, backup the /tools linker, - and replace it with the adjusted linker we made in chapter 5. We'll also create - a link to its counterpart in - /tools/$(uname -m)-pc-linux-gnu/bin: - -mv -v /tools/bin/{ld,ld-old} -mv -v /tools/$(uname -m)-pc-linux-gnu/bin/{ld,ld-old} -mv -v /tools/bin/{ld-new,ld} -ln -sv /tools/bin/ld /tools/$(uname -m)-pc-linux-gnu/bin/ld - - the next command amends the GCC specs file to achieve three goals: - first point GCC to the new dynamic linker. Simply deleting all instances of - /tools should leave us with the correct path to the dynamic - linker. Second, let GCC know where to find the Glibc start files. Third, - add the /usr/include directory at the end of the default search path, so - that header files added in chapter 6 are found. - A sed command accomplishes this: - -gcc -dumpspecs | sed -e 's@/tools@@g' \ - -e '/\*startfile_prefix_spec:/{n;s@.*@/usr/lib/ @}' \ - -e '/\*cpp:/{n;s@$@ -idirafter /usr/include@}' > \ - `dirname $(gcc --print-libgcc-file-name)`/specs - - It is a good idea to visually inspect the specs file to verify the - intended change was actually made. - - It is imperative at this point to ensure that the basic - functions (compiling and linking) of the adjusted toolchain are working - as expected. To do this, perform the following sanity checks: - -echo 'int main(){}' > dummy.c -cc dummy.c -v -Wl,--verbose &> dummy.log -readelf -l a.out | grep ': /lib' - - There should be no errors, - and the output of the last command will be (allowing for - platform-specific differences in the dynamic linker name): - -[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2] - - Note that on 64-bit systems /lib is - the location of our dynamic linker, but is accessed via a symbolic link - in /lib64. - - On 32-bit systems the interpreter should be - /lib/ld-linux.so.2. - - Now make sure that we're setup to use the correct start files: - -grep -o '/usr/lib.*/crt[1in].*succeeded' dummy.log - - The output of the last command should be: - -/usr/lib/../lib/crt1.o succeeded -/usr/lib/../lib/crti.o succeeded -/usr/lib/../lib/crtn.o succeeded - - Verify that the compiler is searching for the correct header - files: - -grep -B4 '^ /usr/include' dummy.log - - This command should return the following output: - -#include <...> search starts here: - /tools/lib/gcc/x86_64-pc-linux-gnu/&gcc-version;/include - /tools/include - /tools/lib/gcc/x86_64-pc-linux-gnu/&gcc-version;/include-fixed - /usr/include - - On a 32 bit system, x86_64 is replaced with i686. - - Next, verify that the new linker is being used with the correct search paths: - -grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' - - References to paths that have components with '-linux-gnu' should - be ignored, but otherwise the output of the last command should be: - -SEARCH_DIR("/usr/lib") -SEARCH_DIR("/lib") - - Next make sure that we're using the correct libc: - -grep "/lib.*/libc.so.6 " dummy.log - - The output of the last command should be: - -attempt to open /usr/lib/libc.so.6 succeeded - - Make sure GCC is using the correct dynamic linker: - -grep found dummy.log - - The output of the last command should be (allowing for - platform-specific differences in dynamic linker name): - -found ld-linux-x86-64.so.2 at /usr/lib/ld-linux-x86-64.so.2 - - If the output does not appear as shown above or is not received - at all, then something is seriously wrong. Investigate and retrace the - steps to find out where the problem is and correct it. Any - issues will need to be resolved before continuing with the process. - - Once everything is working correctly, clean up the test files: - -rm -v dummy.c a.out dummy.log - - diff --git a/chapter08/gcc.xml b/chapter08/gcc.xml index cd3a9b9fe..4c62a8d17 100644 --- a/chapter08/gcc.xml +++ b/chapter08/gcc.xml @@ -197,29 +197,21 @@ rm -rf /usr/lib/gcc/$(gcc -dumpmachine)/&gcc-version;/include-fixed/bits/ - +echo 'int main(){}' > dummy.c +cc dummy.c -v -Wl,--verbose &> dummy.log +readelf -l a.out | grep ': /lib' - + There should be no errors, + and the output of the last command will be (allowing for + platform-specific differences in the dynamic linker name): - +[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2] - + Now make sure that we're setup to use the correct start files: - +grep -o '/usr/lib.*/crt[1in].*succeeded' dummy.log - + The output of the last command should be: /usr/lib/gcc/x86_64-pc-linux-gnu/&gcc-version;/../../../../lib/crt1.o succeeded /usr/lib/gcc/x86_64-pc-linux-gnu/&gcc-version;/../../../../lib/crti.o succeeded @@ -232,15 +224,12 @@ rm -rf /usr/lib/gcc/$(gcc -dumpmachine)/&gcc-version;/include-fixed/bits/crt*.o files under the /usr/lib directory. - + Verify that the compiler is searching for the correct header + files: grep -B4 '^ /usr/include' dummy.log - + This command should return the following output: #include <...> search starts here: /usr/lib/gcc/x86_64-pc-linux-gnu/&gcc-version;/include @@ -251,17 +240,12 @@ rm -rf /usr/lib/gcc/$(gcc -dumpmachine)/&gcc-version;/include-fixed/bits/Again, the directory named after your target triplet may be different than the above, depending on your system architecture. - + Next, verify that the new linker is being used with the correct search paths: - +grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' - + References to paths that have components with '-linux-gnu' should + be ignored, but otherwise the output of the last command should be: SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib64") SEARCH_DIR("/usr/local/lib64") @@ -284,49 +268,32 @@ SEARCH_DIR("/usr/local/lib") SEARCH_DIR("/lib") SEARCH_DIR("/usr/lib"); - + Next make sure that we're using the correct libc: - +grep "/lib.*/libc.so.6 " dummy.log - + The output of the last command should be: - +attempt to open /usr/lib/libc.so.6 succeeded - + Make sure GCC is using the correct dynamic linker: - +grep found dummy.log - + The output of the last command should be (allowing for + platform-specific differences in dynamic linker name): - +found ld-linux-x86-64.so.2 at /usr/lib/ld-linux-x86-64.so.2 - + If the output does not appear as shown above or is not received + at all, then something is seriously wrong. Investigate and retrace the + steps to find out where the problem is and correct it. Any + issues will need to be resolved before continuing with the process. - + Once everything is working correctly, clean up the test files: - +rm -v dummy.c a.out dummy.log Finally, move a misplaced file: -- cgit v1.2.3-54-g00ecf