Jonathan Wakely <jwakely.gcc <at> gmail.com> writes: > > 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 <at> 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. Thanks. So, wouldn't it make sense for the compiler to use its own, newer version of this library for the binaries it builds ? Will the gcc configure script honor my LDFLAGS or LD_RUN_PATH and if I add /opt/ci1/toolchain/tc8.2/sles11sp1_gcc-4.8.1_x86-64/gcc-4.8.1/lib64 to them ? > > 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 > Thanks. Yes, I'm aware of this. We add the GCC 4.8.1 library directory to both the linker search path and run path for everything we build.
