On 5 May 2013 17:31, Dennis Clarke wrote: > > [ long winding and weaving reply ahead .. sorry ] > >> >> 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? > > yep. clearly something I dragged over from one of my Solaris build servers. > Should be harmless, but useless also. > >> > LD_RUN_PATH would cause your issue though. Don't do that. > > I was wondering if the libs in /usr/local/gcc4/lib are being found and they > belong to GCC 4.7.3 as opposed to 4.8.0 and .. I see yes, you have mentioned > that below. It's what I said five days ago in my first reply in this thread :-) >> 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. > > Generally I tend to stick with a procedure of "test first" then if that looks okay, > I install. This is a chicken and egg case where I need to install first and then > run tests. Seems reasonable given that changes that have happened in the > GCC 4.8.x world. It's nothing to do with "changes in the GCC 4.8.x world" it's because you're setting LD_RUN_PATH to a location which contains incompatible versions of libstdc++.so >> Is there a reason you're putting /usr/local/lib in the RPATH? Isn't it >> in the default paths searched by ldconfig anyway? To answer my own question, no, it isn't. Sorry, I didn't bother reading the rest of you mail, since the answer to my question is simply "no".
