Re: AIX trunk build fail #3

[Perry Smith <pedzsan at gmail dot com>]

On Oct 24, 2012, at 11:28 AM, Perry Smith wrote:

> 
> On Oct 24, 2012, at 11:20 AM, Jonathan Wakely wrote:
> 
>> On 24 October 2012 15:10, Perry Smith wrote:
>>> I thought I found a pilot error last night but it made no difference.  I was calling "make" and not "make bootstrap".
>> 
>> Just "make" is correct, and has been for many years now.
> 
> Thanks.  Any ideas of why it dies a different death the second pass?  It makes debugging my original problem harder.

To recap, there are two questions:

2) why does "make" a second time go down a different path?

The reason is because powerpc-ibm-aix6.1.0.0/libatomic exists and the code for configure-target-libatomic (and others) does an exit 0 if the directory exists (assuming all is well and good).  Otherwise, it continues on and does work.  So... there needs to be a catch to delete the directory when something fails (which may be a really bad idea) or touch a file when it is done to know that it completed successfully.  Testing just the directory (which is created at the start of the processing) is not correct.

1b) What is the story of LD_LIBRARY_PATH?

AIX started looking at LD_LIBRARY_PATH in 6.1 gold.  You can do a search of LD_LIBRARY_PATH here 

http://pic.dhe.ibm.com/infocenter/aix/v6r1/index.jsp 

and get some hits.  Not sure why Google didn't cough that out previously.  It usually does.

Note: some people may find searching for LDR_PRELOAD interesting as well.  I didn't take the time to fully read it and understand it.

1a) why is the configure failing?

Because LD_LIBRARY_PATH is being set to the 64 bit path on the invocation of xgcc (and cc1).  So, the loader tries to load the libraries from the path it has been told to load them from.

I'm not clear why LD_LIBRARY_PATH is now being set.

This also changes a previous statement I made: while I did build 4.5.2 on a different level of AIX, it was a 6.1 level and has the same LD_LIBRARY_PATH feature.  Thus, something has changed in the build process of gcc to include LD_LIBRARY_PATH into the environment before calling xgcc since 4.5.2 was released.  At least, that is my current theory.

Just to satisfy my curiosity, I will build 4.5.2 on the same machine I'm now using to verify what I just said.

Thank you,
Perry Smith