AIX library issues

[Perry Smith <pedzsan@gmail.com>]

I've discovered an issue which I can't believe I'm the first to bump
in to.  But I've checked older gcc installs and find the same issue.
I did a brief internet search and found sorta similar issues but I'm
not sure if they explained it as I see it.

I bumped into this while trying to build lzma.  What follows is from a
gcc 4.5.2 build using gcc 4.5.2 to compile it running AIX 6.1 TL05
SP06.  But, as I said, I've compared this to output produced by a gcc
4.3.1 running on AIX 5.3 with the same results.

On AIX, there is a tool called dump.  dump -H <file> dumps out the
header of the loader section.

When I link lzma and try to run it, it dies with a long error (that I
won't post).  In essence it boils down to this: lzma needs libstdc++.
In that archive is one shared object.  The loader can find lzma and
can find the libstdc++ object but it can not load either because
libstc++ depends upon another library that the loader can not find.
Here is why:

dump -H libstdc++.so.6

./powerpc-ibm-aix6.1.0.0/libstdc++-v3/src/.libs/libstdc++.so.6.orig:

                        ***Loader Section***
                      Loader Header Information
VERSION#         #SYMtableENT     #RELOCent        LENidSTR
0x00000001       0x00000fe0       0x000033b6       0x000000da       

#IMPfilID        OFFidSTR         LENstrTBL        OFFstrTBL
0x00000003       0x0003e9a8       0x0002dec7       0x0003ea82       


                        ***Import File Strings***
INDEX  PATH                          BASE                MEMBER              
0      /usr/work/build/gcc-4.5.2/powerpc-ibm-aix6.1.0.0/libstdc++-v3/src:/usr/work/build/gcc-4.5.2/powerpc-ibm-aix6.1.0.0/libstdc++-v3/src/.libs:/usr/work/build/gcc-4.5.2/./gcc:/usr/lib:/lib                                         
1                                    libc.a              shr.o               
2                                    libgcc_s.a          shr.o               

What this is telling us is that libstdc++.so.6 needs libc.a(shr.o) and
libgcc_s.a(shr.o) and it is also telling us that when libc.a(shr.o)
and libgcc_s.a(shr.o) is needed at run time, the list of places
searched is the list of directories listed in entry 0.  But the list
is the list of where the library is built -- not where it (or more
importantly where libgcc_s.a) will be installed.  When I configured
and built this gcc, prefix path was set to
/gsa/ausgsa/projects/r/ruby.

Here are the first few lines of my config.log:

 /usr/work/src/gcc-4.5.2/configure --prefix=/gsa/ausgsa/projects/r/ruby --with-gmp=/gsa/ausgsa/projects/r/ruby --with-mpfr=/gsa/ausgsa/projects/r/ruby --with-mpc=/gsa/ausgsa/projects/r/ruby --disable-nls --enable-threads=aix --with-libiconv-prefix=/usr --enable-languages=c,c++

I have told configure that /gsa/ausgsa/projects/r/ruby is the place I
plan to install this compiler.  Yet its search path does not include
this path at all.  For most (perhaps all) of the other shared objects,
the path doesn't make THAT much difference because the only library
needed is libc.a and it will be found in /usr/lib.

The executables suffer from the same thing.  Again, it doesn't seem to
matter since they only include libc.a.

I've been told but I do not know for sure that libtool understands
AIX's peculiarities.  In particular, what needs to happen is a relink
needs to be done.  The executables and libraries are correct for
testing the results in the current directory.  But they are not
correct when the final result is moved into the place it was designed
to go in to.

The good news is that a program compiled with gcc produces an object
file with the proper path so all the programs produced from the final
gcc are correct.

I'm fairly sure that this isn't a pilot error (I somehow botched the
call to configure or something like that) but I sure would be happy to
find out it was my fault.  This seems like a rather hard nut to crack.

I hope all this is clear.  I'm more than happy to help out in solving
this.

Thank you,
pedz