Context Navigation

-              rb711e1d
+              r574b0ea
 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>
 …
 <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
 …
 <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>
 …
 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&gt;&amp;1 | grep succeeded</command>
+passing the <parameter>--verbose</parameter> switch to the linker. For example:
+<userinput>gcc dummy.c -Wl,--verbose 2&gt;&amp;1 | grep succeeded</userinput>
 will show you all the files successfully opened during the linking.</para>
 …
 <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
 …
 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>
 …
 <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
 …
 <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
 …
 hard-wired path to a dynamic linker is embedded into every ELF shared
 executable. You can inspect this by running:
 <command>readelf -l &lt;name of binary&gt; | grep interpreter</command>.
+<userinput>readelf -l &lt;name of binary&gt; | 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
 …
 <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

Note: See TracChangeset for help on using the changeset viewer.

Context Navigation

Changeset 574b0ea for chapter05/toolchaintechnotes.xml

Legend:

chapter05/toolchaintechnotes.xml

Download in other formats: