Re: pitiful results for GCC 4.8.0

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

On 5 May 2013 12:32, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> 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.

Or if you do, don't have the older GCC libs in those paths, as they
are being found and that's what causes the test failures.  Once you've
installed the newer GCC you might find the tests results are better,
because the older libs don't get found.

Is there a reason you're putting /usr/local/lib in the RPATH? Isn't it
in the default paths searched by ldconfig anyway?