On 8 November 2013 14:52, Kris Wempa wrote: > 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 ? If it only depends on libgcc_s.so.1 then it doesn't really matter, as that library isn't supposed to change much IIUC. I'm not sure if the situation is different now that GCC is implemented in C++ and so relies on lisbtdc++.so > 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 > ? I think it honours LD_RUN_PATH, but you might need to use something else like BOOT_LDFLAGS for LDFLAGS, I'm not sure.
