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.
