On 5 May 2013 00:39, Dennis Clarke <dclarke@xxxxxxxxxxxxx> 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.
