Christian Böhme kirjoitti:
I am currently trying to install the 4.2.0 version of GCC on a
Linux system that has not seen much administration work over the past
years.
The problem here is that this new compiler with its updated/
improved/bug-less runtime libraries (such as libgcc_s.so,
libstdc++.so, libgfortran.so) does not explicitly tell the linker
to link against them (or set DT_RUNPATH in the resulting executables
accordingly) but to use what is setup by the sysadmin (via
/etc/ld.so.conf
and friends).
The GNU linker knows the '-rpath-link <libpath>' and '-rpath <libpath>'
options
to force the pointed shared libs being searched at 'linktime' when
producing the
executable and at 'runtime' when running that executable. So the latter
would be
what you will need... You could use it in every compile/link command or
put it
into the 'specs' file of the new gcc-4.2.0, into the same 'spec' where that
'--dynamic-linker /lib/ld-linux.so.2' is...
Consequently, I reverted back to configuring with static
runtime libraries which even more surprisingly yielded the same result.
It appears that g++ only passes a lone -lstdc++ to the linker
but not the path where GCC supposedly installed its own sparkly
new libraries (either shared or static).
Surprisingly GCC DOESN'T as default install its $target/$gcc-version
specific link-time libraries into the expected $target/$gcc-version
directory:
$prefix/lib/gcc/$target/$gcc-version
where it searches these libraries first! But puts them into the 'native
search
place', '/usr/lib' or into some other totally unexpected place :-( So
people
like me have learned to NOT use the 'make install' and use their own local
install template scripts for putting things where they should go
following the
GCC builder's opinions... OR use the :
--enable-version-specific-runtime-libs
GCC configure option (as you did!) in order to put the produced libs
into that '$prefix/lib/gcc/$target/$gcc-version'! In any case the goal
could be to use the $target/$gcc-version specific install directory for
the stuff required at link-time,
it will be used automatically and first! Just check with the 'g++
-print-search-dirs'.
For the run-time issue using the '-rpath <libdir>' marks every produced
executable
to search the shared libraries first from the '<libdir>' before going
to the native
'/lib' and '/usr/lib', '/usr/local/lib' etc. What this "alternative
search place" could be
is then totally dependent on your tastes... But '/opt/lib' could
sound nice for me...
The '-rpath <libdir>' can be given on the GCC 'compile&link' command like:
g++ -Wl,-rpath,<libdir> -O2 -o hello hello.cpp
using the '-Wl,<linker-options>' GCC option for giving extra options to
the linker.
That there really is a new built-in/hard-wired RPATH stamped into the
executable
can be seen via 'objdump' like:
objdump -p hello
