diff options
Diffstat (limited to 'chapter05/toolchaintechnotes.xml')
| -rw-r--r-- | chapter05/toolchaintechnotes.xml | 38 |
1 files changed, 19 insertions, 19 deletions
diff --git a/chapter05/toolchaintechnotes.xml b/chapter05/toolchaintechnotes.xml index d9ea431d6..666e181e2 100644 --- a/chapter05/toolchaintechnotes.xml +++ b/chapter05/toolchaintechnotes.xml @@ -27,19 +27,19 @@ words, more advanced techniques could be used to build the system.</para> platform, often also referred to as the <emphasis>target triplet</emphasis>. For many folks the target triplet will probably be <emphasis>i686-pc-linux-gnu</emphasis>. A simple way to determine your target -triplet is to run the <filename>config.guess</filename> script that comes with +triplet is to run the <command>config.guess</command> script that comes with the source for many packages. Unpack the Binutils sources and run the script: <userinput>./config.guess</userinput> and note the output.</para> <para>You'll also need to be aware of the name of your platform's <emphasis>dynamic linker</emphasis>, often also referred to as the <emphasis>dynamic loader</emphasis>, not to be confused with the standard linker -<emphasis>ld</emphasis> that is part of Binutils. The dynamic linker is provided +<command>ld</command> that is part of Binutils. The dynamic linker is provided by Glibc and has the job of finding and loading the shared libraries needed by a program, preparing the program to run and then running it. For most folks the -name of the dynamic linker will be <emphasis>ld-linux.so.2</emphasis>. On +name of the dynamic linker will be <filename>ld-linux.so.2</filename>. On platforms that are less prevalent, the name might be -<emphasis>ld.so.1</emphasis> and newer 64 bit platforms might even have +<filename>ld.so.1</filename> and newer 64 bit platforms might even have something completely different. You should be able to determine the name of your platform's dynamic linker by looking in the <filename class="directory">/lib</filename> directory on your host system. A @@ -63,7 +63,7 @@ path to ensure programs are linked only against libraries we choose.</para></listitem> <listitem><para>Careful manipulation of <command>gcc</command>'s -<emphasis>specs</emphasis> file to tell the compiler which target dynamic +<filename>specs</filename> file to tell the compiler which target dynamic linker will be used.</para></listitem> </itemizedlist> @@ -81,29 +81,29 @@ much time is wasted.</para> <filename class="directory">/tools/$TARGET_TRIPLET/bin</filename>. In reality, 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 <command>ld</command> by passing it the <emphasis>--verbose</emphasis> +from <command>ld</command> by passing it the <parameter>--verbose</parameter> flag. For example: <command>ld --verbose | grep SEARCH</command> will show you the current search paths and their order. You can see what files are actually linked by <command>ld</command> by compiling a dummy program and -passing the <emphasis>--verbose</emphasis> switch to the linker. For example: -<command>gcc dummy.c -Wl,--verbose 2>&1 | grep succeeded</command> +passing the <parameter>--verbose</parameter> switch to the linker. For example: +<userinput>gcc dummy.c -Wl,--verbose 2>&1 | grep succeeded</userinput> will show you all the files successfully opened during the linking.</para> <para>The next package installed is GCC and during its run of <command>./configure</command> you'll see, for example:</para> -<blockquote><screen>checking what assembler to use... /tools/i686-pc-linux-gnu/bin/as -checking what linker to use... /tools/i686-pc-linux-gnu/bin/ld</screen></blockquote> +<blockquote><screen><computeroutput>checking what assembler to use... /tools/i686-pc-linux-gnu/bin/as +checking what linker to use... /tools/i686-pc-linux-gnu/bin/ld</computeroutput></screen></blockquote> <para>This is important for the reasons mentioned above. It also demonstrates that GCC's configure script does not search the PATH directories to find which tools to use. However, during the actual operation of <command>gcc</command> itself, the same search paths are not necessarily used. You can find out which standard linker <command>gcc</command> will use by running: -<command>gcc -print-prog-name=ld</command>. +<userinput>gcc -print-prog-name=ld</userinput>. Detailed information can be obtained from <command>gcc</command> by passing -it the <emphasis>-v</emphasis> flag while compiling a dummy program. For -example: <command>gcc -v dummy.c</command> will show you detailed +it the <parameter>-v</parameter> flag while compiling a dummy program. For +example: <userinput>gcc -v dummy.c</userinput> will show you detailed information about the preprocessor, compilation and assembly stages, including <command>gcc</command>'s include search paths and their order.</para> @@ -117,15 +117,15 @@ switches to enforce the correct selections. After the run of <filename>config.make</filename> file in the <filename class="directory">glibc-build</filename> directory for all the important details. You'll note some interesting items like the use of -<emphasis>CC="gcc -B/tools/bin/"</emphasis> to control which binary tools are -used, and also the use of the <emphasis>-nostdinc</emphasis> and -<emphasis>-isystem</emphasis> flags to control the compiler's include search +<parameter>CC="gcc -B/tools/bin/"</parameter> to control which binary tools are +used, and also the use of the <parameter>-nostdinc</parameter> and +<parameter>-isystem</parameter> flags to control the compiler's include search path. These items help to highlight an important aspect of the Glibc package: it is very self-sufficient in terms of its build machinery and generally does not rely on toolchain defaults.</para> <para>After the Glibc installation, we make some adjustments to ensure that -searching and linking take place only within our <filename>/tools</filename> +searching and linking take place only within our <filename class="directory">/tools</filename> prefix. We install an adjusted <command>ld</command>, which has a hard-wired search path limited to <filename class="directory">/tools/lib</filename>. Then we amend <command>gcc</command>'s specs file to point to our new dynamic @@ -133,7 +133,7 @@ linker in <filename class="directory">/tools/lib</filename>. This last step is <emphasis>vital</emphasis> 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: -<command>readelf -l <name of binary> | grep interpreter</command>. +<userinput>readelf -l <name of binary> | grep interpreter</userinput>. By amending <command>gcc</command>'s specs file, we are ensuring that every program compiled from here through the end of this chapter will use our new dynamic linker in <filename class="directory">/tools/lib</filename>.</para> @@ -145,7 +145,7 @@ programs themselves having the name of the dynamic linker from the host system's would defeat our goal of getting away from the host.</para> <para>During the second pass of Binutils, we are able to utilize the -<emphasis>--with-lib-path</emphasis> configure switch to control +<parameter>--with-lib-path</parameter> configure switch to control <command>ld</command>'s library search path. From this point onwards, the core toolchain is self-contained and self-hosted. The remainder of the <xref linkend="chapter-temporary-tools"/> packages all build against the new Glibc in |