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

Jonathan Wakely
Fri Nov 8 15:44:00 GMT 2013

On 8 November 2013 14:52, Kris Wempa wrote:
> Jonathan Wakely <jwakely.gcc <at>> 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 and others are linked to the one built for the
>> > 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
>> > => /lib64/ (0x00007f57377f2000)
>> This is expected. The binaries are simply linked to "",
>> 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 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

> 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.

More information about the Gcc-help mailing list