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

[Kris Wempa <Kristofer dot Wempa at sig dot com>]

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.