On Oct 22, 2012, at 8:55 AM, Michael Haubenwallner wrote: > On 10/22/2012 03:49 PM, Perry Smith wrote: >> In stage 3, libatomic's configure fails. The config.log file is here: >> https://gist.github.com/3931504 >> >> I've recreated the conftest.c and ran the same command. The output is fine >> and executes with a 0 status. >> >> The clue (that I can't figure out) is cc1 is a 32 bit program but it tried >> to load the 64 bit version of libstdc++. >> I can't figure out why it tried to do that and I can't recreate it. > > This one is (similar to) http://gcc.gnu.org/PR52623
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52623#c4 I bet that is my problem. LD_LIBRARY_PATH has the first element is the same path that the loader decided to find libstdc++. I will find the APAR(s) that introduced this later and post it. (I'm speculating here...) The dance that needs to happen is it can not be in the real environment or the loader will see it and gcc or other executables will start to fail. But it needs to use it when it creates the internal libpath for the executable. I am on 6.1 and the comment says 7.1 but usually features are dropped to both. e.g. a 6.1 TL will come out the same time that a 7.1 TL comes out with a lot of the same features. I'm a bit under the weather right now. I will dig into this eventually but it might take a while. Note: my previous work was done on 6.1 TL05 SP07 so... I moved machines. That is probably why I'm hitting this now whereas I did not hit it before. Thank you to all Perry
