Question About Building Newer GCC To Co-Exist With The System One

[Jonathan Wakely]

On 8 November 2013 14:32, Kris Wempa wrote:
> I work on a SLES11 server and I am trying to build a newer GCC compiler and
> use it to build a large set of tools.  The system compiler is GCC 4.3.4 and I
> am building GCC 4.8.1.  While doing sanity tests, I noticed something strange
> with the GCC 4.8.1 compiler that I built.  Some of the binaries are linked to
> the system libgcc_s.so and others are linked to the one built for the GCC
> 4.8.1 compiler.  For example:
>
> ci1admin@dtcci1devbal801:/opt/ci1/toolchain/tc8.2/sles11sp1_gcc-4.8.1_x86-
> 64/gcc-4.8.1/bin> ldd gcc | grep libgcc_s
>         libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f57377f2000)

This is expected. The binaries are simply linked to "libgcc_s.so.1",
not a specific path, which version of that gets used is determined by
the dynamic linker on your system.

The GCC binaries do not embed DT_RPATH or DT_RUNPATH tags to tell the
dynamic linker where to find shared libraries.  This is also true of
binaries built with GCC, you need to tell the dynamic linker how to
find libraries such as libstdc++.so, as described at
http://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dynamic_or_shared.html#manual.intro.using.linkage.dynamic

> ci1admin@dtcci1devbal801:/opt/ci1/toolchain/tc8.2/sles11sp1_gcc-4.8.1_x86-
> 64/gcc-4.8.1/bin> ldd gappletviewer | grep libgcc_s
>         libgcc_s.so.1 => /opt/ci1/toolchain/tc8.2/sles11sp1_gcc-4.8.1_x86-
> 64//gcc-4.8.1/lib/../lib64/libgcc_s.so.1 (0x00007f10052ff000)

Presumably this is also normal, I assume gappletviewer is built with
libjava or the gcj front-end, and it apparently has been built with
DT_RPATH or DT_RUNPATH tags (you could confirm that by using "readelf
-d gappletviewer").  That's not how binaries are built for the rest of
GCC though.