Re: pitiful results for GCC 4.8.0

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

On 5 May 2013 00:39, Dennis Clarke <dclarke@blastwave.org> wrote:
>
>> On 2 May 2013 18:11, Dennis Clarke wrote:
>> >
>> >> On 30 April 2013 01:18, Dennis Clarke wrote:
>> >> >
>> >> > I build GCC 4.8.0 on the exact same platform that I built GCC 4.7.3
>> >> and yet
>> >> > I see really quite different results. Is anyone out there seeing
>> >> clean results
>> >> > from 4.8.0 ?
>> >>
>> >> 4.8.0 wouldn't have been released with all those libstdc++ failures,
>> >> so I'm pretty sure noone else is seeing them.
>> >>
>> >> Try looking in $target/libstdc++-v3/libstdc++.log for what is causing
>> >> the failures, but I suspect it will be undefined references.
>> >>
>> >> All those failing tests rely on symbols that are new to libstdc++.so
>> >> in 4.8.0 so your tests are apparently finding the old libstdc++.so
>> >> from an older compiler, or there's some problem with the linker script
>> >> used to set symbol versions. I don't know why you're seeing this and
>> >> noone else is - it hints the problem is at your end.
>> >
>> > yep.
>> >
>> > I was puzzled because I can build 4.7.3 with the same compiler that
>> I build 4.8.0
>> > in much the same way and get very different results.
>> >
>> > So I have to dig a bit deeper to find .. what is going on here.
>>
>> Do you have LD_LIBRARY_PATH set?
>
> sorry for the great delay.
>
> It looks like I did not have that set.  I did have :
>
> LD=/usr/local/bin/gld
> LDFLAGS=-L/usr/local/lib
> LD_OPTIONS=-R/usr/local/lib:/usr/local/gcc4/lib -L/usr/local/lib:/usr/local/gcc4/lib
> LD_RUN_PATH=/usr/local/lib:/usr/local/gcc4/lib
> LIBTOOL=/usr/local/bin/libtool
>
> Those may be the source of my concern as LD_OPTIONS could be trouble.

I don't think the GNU linker uses LD_OPTIONS, isn't that a Solaris ld
environment variable?

LD_RUN_PATH would cause your issue though.  Don't do that.