|
@@ -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
|
|
of your platform's dynamic linker by looking in the
|
|
|
<filename class="directory">/lib</filename> directory on your host system. A
|
|
<filename class="directory">/lib</filename> directory on your host system. A
|
|
|
surefire way is to inspect a random binary from your host system by running:
|
|
surefire way is to inspect a random binary from your host system by running:
|
|
|
-<userinput>`readelf -l <name of binary> | grep interpreter`</userinput>
|
|
|
|
|
|
|
+<userinput>'readelf -l <name of binary> | grep interpreter'</userinput>
|
|
|
and noting the output. The authoritative reference covering all platforms is in
|
|
and noting the output. The authoritative reference covering all platforms is in
|
|
|
the <filename>shlib-versions</filename> file in the root of the Glibc source
|
|
the <filename>shlib-versions</filename> file in the root of the Glibc source
|
|
|
tree.</para>
|
|
tree.</para>
|
|
@@ -75,11 +75,11 @@ much time is wasted.</para>
|
|
|
the tools in one location are hard linked to the other. An important facet of
|
|
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
|
|
the linker is its library search order. Detailed information can be obtained
|
|
|
from <userinput>ld</userinput> by passing it the <emphasis>--verbose</emphasis>
|
|
from <userinput>ld</userinput> by passing it the <emphasis>--verbose</emphasis>
|
|
|
-flag. For example: <userinput>`ld --verbose | grep SEARCH`</userinput> will
|
|
|
|
|
|
|
+flag. For example: <userinput>'ld --verbose | grep SEARCH'</userinput> will
|
|
|
show you the current search paths and their order. You can see what files are
|
|
show you the current search paths and their order. You can see what files are
|
|
|
actually linked by <userinput>ld</userinput> by compiling a dummy program and
|
|
actually linked by <userinput>ld</userinput> by compiling a dummy program and
|
|
|
passing the <emphasis>--verbose</emphasis> switch. For example:
|
|
passing the <emphasis>--verbose</emphasis> switch. For example:
|
|
|
-<userinput>`gcc dummy.c -Wl,--verbose 2>&1 | grep succeeded`</userinput>
|
|
|
|
|
|
|
+<userinput>'gcc dummy.c -Wl,--verbose 2>&1 | grep succeeded'</userinput>
|
|
|
will show you all the files successfully opened during the link.</para>
|
|
will show you all the files successfully opened during the link.</para>
|
|
|
|
|
|
|
|
<para>The next package installed is GCC and during its run of
|
|
<para>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 <userinput>gcc</userinput>
|
|
tools to use. However, during the actual operation of <userinput>gcc</userinput>
|
|
|
itself, the same search paths are not necessarily used. You can find out which
|
|
itself, the same search paths are not necessarily used. You can find out which
|
|
|
standard linker <userinput>gcc</userinput> will use by running:
|
|
standard linker <userinput>gcc</userinput> will use by running:
|
|
|
-<userinput>`gcc -print-prog-name=ld`</userinput>.
|
|
|
|
|
|
|
+<userinput>'gcc -print-prog-name=ld'</userinput>.
|
|
|
Detailed information can be obtained from <userinput>gcc</userinput> by passing
|
|
Detailed information can be obtained from <userinput>gcc</userinput> by passing
|
|
|
it the <emphasis>-v</emphasis> flag while compiling a dummy program. For
|
|
it the <emphasis>-v</emphasis> flag while compiling a dummy program. For
|
|
|
-example: <userinput>`gcc -v dummy.c`</userinput> will show you detailed
|
|
|
|
|
|
|
+example: <userinput>'gcc -v dummy.c'</userinput> will show you detailed
|
|
|
information about the preprocessor, compilation and assembly stages, including
|
|
information about the preprocessor, compilation and assembly stages, including
|
|
|
<userinput>gcc</userinput>'s include search paths and their order.</para>
|
|
<userinput>gcc</userinput>'s include search paths and their order.</para>
|
|
|
|
|
|
|
@@ -126,7 +126,7 @@ linker in <filename class="directory">/tools/lib</filename>. This last step is
|
|
|
<emphasis>vital</emphasis> to the whole process. As mentioned above, a
|
|
<emphasis>vital</emphasis> to the whole process. As mentioned above, a
|
|
|
hard-wired path to a dynamic linker is embedded into every ELF shared
|
|
hard-wired path to a dynamic linker is embedded into every ELF shared
|
|
|
executable. You can inspect this by running:
|
|
executable. You can inspect this by running:
|
|
|
-<userinput>`readelf -l <name of binary> | grep interpreter`</userinput>.
|
|
|
|
|
|
|
+<userinput>'readelf -l <name of binary> | grep interpreter'</userinput>.
|
|
|
By amending <userinput>gcc</userinput>'s specs file, we are ensuring that every
|
|
By amending <userinput>gcc</userinput>'s specs file, we are ensuring that every
|
|
|
program compiled from here through the end of Chapter 5 will use our new
|
|
program compiled from here through the end of Chapter 5 will use our new
|
|
|
dynamic linker in <filename class="directory">/tools/lib</filename>.</para>
|
|
dynamic linker in <filename class="directory">/tools/lib</filename>.</para>
|
Greg Schafer