AIX library issues

AIX library issues

[Perry Smith]

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

Re: AIX library issues

[Jonathan Wakely]

On 18 October 2011 03:05, Perry Smith wrote:
> I've discovered an issue which I can't believe I'm the first to bump
> in to.

Isn't this covered by these FAQs?
http://gcc.gnu.org/faq.html#rpath
http://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.how_to_set_paths

Re: AIX library issues

[Jonathan Wakely]

On 18 October 2011 09:21, Jonathan Wakely wrote:
> On 18 October 2011 03:05, Perry Smith wrote:
>> I've discovered an issue which I can't believe I'm the first to bump
>> in to.
>
> Isn't this covered by these FAQs?
> http://gcc.gnu.org/faq.html#rpath
> http://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.how_to_set_paths
>

See also http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32354 although if
AIX doesn't support $ORIGIN then the suggested configure-time option
wouldn't be so useful, as the path couldn't be relative and the gcc
installation wouldn't be relocatable.

Re: AIX library issues

[David Edelsohn]

On Mon, Oct 17, 2011 at 10:05 PM, Perry Smith <pedzsan@gmail.com> wrote:

> 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++

AIX inserts the list of libraries provided with -L options on the link
command line into the default search path.  If you want, you can edit
libtool created for libstdc++ to add
-Wl,-blibpath:/gsa/ausgsa/projects/r/ruby/lib:/usr/lib:/lib and relink
libstdc++ (or edit the path in the shared object header directly).

- David

Re: AIX library issues

[Perry Smith]

On Oct 18, 2011, at 9:59 AM, David Edelsohn wrote:

> On Mon, Oct 17, 2011 at 10:05 PM, Perry Smith <pedzsan@gmail.com> wrote:
> 
>> dump -H libstdc++.so.6
>> 
>> ...

>>  /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++
> 
> AIX inserts the list of libraries provided with -L options on the link
> command line into the default search path.  If you want, you can edit
> libtool created for libstdc++ to add
> -Wl,-blibpath:/gsa/ausgsa/projects/r/ruby/lib:/usr/lib:/lib and relink
> libstdc++ (or edit the path in the shared object header directly).

I'm working on a real solution to this but bumped into a question:

libgomp.so.1 wants libc.a, libpthreads.a, and libgcc_s.a.  The first two do not present a problem.  But there are four libgcc_s.a (normal, ppc64, pthread, and ppc64+pthread).

Note that there is also four versions of libgomp.so.1 (normal, ppc64, pthread, ppc64+pthread).

My question is: which libgcc_s.a should I link to?  (this question is for each of the four versions of libgomp.so.1).

Setting LIBPATH or whatever I do is going to override the internal path (since the internal path is broken).  So, this may be a question that has never been asked or answered.

My knee jerk is that the normal libgomp.so.1 wants the normal libgcc_s.a, the ppc64 wants the ppc64, etc.  But I notice that it will always include pthread so that is what caused me to pause and ask.

Part of me wonders if the two non-pthread versions of libgomp make any sense.  I don't really know anything about libgomp.

Thank you for your time
pedz

Re: AIX library issues

[David Edelsohn]

On Sun, Oct 23, 2011 at 10:16 AM, Perry Smith <pedzsan@gmail.com> wrote:

> libgomp.so.1 wants libc.a, libpthreads.a, and libgcc_s.a.  The first two do not present a problem.  But there are four libgcc_s.a (normal, ppc64, pthread, and ppc64+pthread).
>
> Note that there is also four versions of libgomp.so.1 (normal, ppc64, pthread, ppc64+pthread).
>
> My question is: which libgcc_s.a should I link to?  (this question is for each of the four versions of libgomp.so.1).
>
> Setting LIBPATH or whatever I do is going to override the internal path (since the internal path is broken).  So, this may be a question that has never been asked or answered.
>
> My knee jerk is that the normal libgomp.so.1 wants the normal libgcc_s.a, the ppc64 wants the ppc64, etc.  But I notice that it will always include pthread so that is what caused me to pause and ask.
>
> Part of me wonders if the two non-pthread versions of libgomp make any sense.  I don't really know anything about libgomp.

libgomp (-fopenmp) does not make sense without pthreads.  -fopenmp
implies pthreads.

One thing to note: AIX tools default to 32 bit mode, although all
systems are 64 bit, unlike GNU/Linux, which defaults to 64 bit mode
(on x86-64 and PPC64).

Only two of the four libgomp multilibs truly are necessary, but
avoiding the non-pthread builds is not worth the trouble.  The
non-pthread libgomp libraries never will be used, unless GCC is
invoked incorrectly.  Each library, including libgomp, should list its
multilib install directory first, e.g., ppc64 pthread would be

-Wl,-blibpath:.../lib/gcc/powerpc-ibm-aix6.1.3.0/4.6.0/pthread/ppc64:.../lib/pthread/ppc64:/usr/lib:/lib

and default would be

-Wl,-blibpath:.../lib/gcc/powerpc-ibm-aix6.1.3.0/4.6.0:.../lib:/usr/lib:/lib

The GCC build process and driver directory search process make a lot
of assumptions that the system directories follow a Linux/SVR4/Solaris
layout.  To follow AIX style, the PPC64 and PPC32 non-reentrant
(non-pthreads) libraries should be archived into the same file
libgomp.a (which never would be referenced) and the reentrant
(pthreads) libraries for PPC64 and PPC32 should be archived into
libgomp_r.a.  The benefit has not been shown to be worth the effort.

- David

Re: AIX library issues

[Perry Smith]

On Oct 23, 2011, at 1:59 PM, David Edelsohn wrote:

> On Sun, Oct 23, 2011 at 10:16 AM, Perry Smith <pedzsan@gmail.com> wrote:
> 
>> libgomp.so.1 wants libc.a, libpthreads.a, and libgcc_s.a.  The first two do not present a problem.  But there are four libgcc_s.a (normal, ppc64, pthread, and ppc64+pthread).
>> 
>> Note that there is also four versions of libgomp.so.1 (normal, ppc64, pthread, ppc64+pthread).
>> 
>> My question is: which libgcc_s.a should I link to?  (this question is for each of the four versions of libgomp.so.1).
>> 
>> Setting LIBPATH or whatever I do is going to override the internal path (since the internal path is broken).  So, this may be a question that has never been asked or answered.
>> 
>> My knee jerk is that the normal libgomp.so.1 wants the normal libgcc_s.a, the ppc64 wants the ppc64, etc.  But I notice that it will always include pthread so that is what caused me to pause and ask.
>> 
>> Part of me wonders if the two non-pthread versions of libgomp make any sense.  I don't really know anything about libgomp.
> 
> libgomp (-fopenmp) does not make sense without pthreads.  -fopenmp
> implies pthreads.
> 
> One thing to note: AIX tools default to 32 bit mode, although all
> systems are 64 bit, unlike GNU/Linux, which defaults to 64 bit mode
> (on x86-64 and PPC64).
> 
> Only two of the four libgomp multilibs truly are necessary, but
> avoiding the non-pthread builds is not worth the trouble.  The
> non-pthread libgomp libraries never will be used, unless GCC is
> invoked incorrectly.  Each library, including libgomp, should list its
> multilib install directory first, e.g., ppc64 pthread would be
> 
> -Wl,-blibpath:.../lib/gcc/powerpc-ibm-aix6.1.3.0/4.6.0/pthread/ppc64:.../lib/pthread/ppc64:/usr/lib:/lib
> 
> and default would be
> 
> -Wl,-blibpath:.../lib/gcc/powerpc-ibm-aix6.1.3.0/4.6.0:.../lib:/usr/lib:/lib
> 
> The GCC build process and driver directory search process make a lot
> of assumptions that the system directories follow a Linux/SVR4/Solaris
> layout.  To follow AIX style, the PPC64 and PPC32 non-reentrant
> (non-pthreads) libraries should be archived into the same file
> libgomp.a (which never would be referenced) and the reentrant
> (pthreads) libraries for PPC64 and PPC32 should be archived into
> libgomp_r.a.  The benefit has not been shown to be worth the effort.

Thanks David,

One more question on this quest (drifting a little more off topic).

In my log files I see a lot of these errors:

> ld: 0711-768 WARNING: Object ../libsupc++/.libs/libsupc++convenience.a[eh_terminate.o], section 1, function .std::terminate():
>         The branch at address 0x10c is not followed by a recognized no-op
>         or TOC-reload instruction. The unrecognized instruction is 0x0.

The build continues and completes.  I just want to make sure that I can safely ignore them.  Surfing the web, sometimes I see people flag the as errors and other times not.

Thank you again,
pedz

Re: AIX library issues

[David Edelsohn]

On Sun, Oct 23, 2011 at 8:33 PM, Perry Smith <pedzsan@gmail.com> wrote:

> One more question on this quest (drifting a little more off topic).
> In my log files I see a lot of these errors:
>
> ld: 0711-768 WARNING: Object
> ../libsupc++/.libs/libsupc++convenience.a[eh_terminate.o], section 1,
> function .std::terminate():
>         The branch at address 0x10c is not followed by a recognized no-op
>         or TOC-reload instruction. The unrecognized instruction is 0x0.
>
> The build continues and completes.  I just want to make sure that I can
> safely ignore them.  Surfing the web, sometimes I see people flag the as
> errors and other times not.

G++ probably is performing an optimization because the terminate
function will not return, so I suspect the error message can be
ignored.

GCC does not always generate completely conformant AIX assembly code
and the AIX assembler does not always follow the rule to be liberal in
what it accepts.

The biggest problem is that AIX users of GCC ask questions here and on
other forums, but do not communicate to IBM AIX Brand executives that
the GNU Toolchain on AIX is important.  The fact that GCC continues to
function at all on AIX seem to place it in the "out of sight, out of
mind" category.

If you are a developer or ISV or your company uses GCC on AIX, tell
your IBM sales representative or executive contact that it is
important to your business.

- David

Re: AIX library issues

[Richard Guenther]

On Tue, Oct 25, 2011 at 1:25 AM, David Edelsohn <dje.gcc@gmail.com> wrote:
> On Sun, Oct 23, 2011 at 8:33 PM, Perry Smith <pedzsan@gmail.com> wrote:
>
>> One more question on this quest (drifting a little more off topic).
>> In my log files I see a lot of these errors:
>>
>> ld: 0711-768 WARNING: Object
>> ../libsupc++/.libs/libsupc++convenience.a[eh_terminate.o], section 1,
>> function .std::terminate():
>>         The branch at address 0x10c is not followed by a recognized no-op
>>         or TOC-reload instruction. The unrecognized instruction is 0x0.
>>
>> The build continues and completes.  I just want to make sure that I can
>> safely ignore them.  Surfing the web, sometimes I see people flag the as
>> errors and other times not.
>
> G++ probably is performing an optimization because the terminate
> function will not return, so I suspect the error message can be
> ignored.
>
> GCC does not always generate completely conformant AIX assembly code
> and the AIX assembler does not always follow the rule to be liberal in
> what it accepts.
>
> The biggest problem is that AIX users of GCC ask questions here and on
> other forums, but do not communicate to IBM AIX Brand executives that
> the GNU Toolchain on AIX is important.  The fact that GCC continues to
> function at all on AIX seem to place it in the "out of sight, out of
> mind" category.
>
> If you are a developer or ISV or your company uses GCC on AIX, tell
> your IBM sales representative or executive contact that it is
> important to your business.

I wonder if it might make sense to more strongly suggest to use GNU as
on AIX?  The install manual currently says

The native @command{as} and @command{ld} are recommended for bootstrapping
on AIX@.  The GNU Assembler, GNU Linker, and GNU Binutils version 2.20
is required to bootstrap on AIX 5@.  The native AIX tools do
interoperate with GCC@.

What's the downside of not using the native AIX tools at all (assembler
and linker)?

Richard.

> - David
>

Re: AIX library issues

[Arnaud Charlet]

> I wonder if it might make sense to more strongly suggest to use GNU as
> on AIX?  The install manual currently says
> 
> The native @command{as} and @command{ld} are recommended for
> bootstrapping
> on AIX@.  The GNU Assembler, GNU Linker, and GNU Binutils version 2.20
> is required to bootstrap on AIX 5@.  The native AIX tools do
> interoperate with GCC@.
> 
> What's the downside of not using the native AIX tools at all (assembler
> and linker)?

FWIW, we've recently made this choice/switch for GNAT at AdaCore, which
allows us in particular to use dwarf-2/3 debug info.

Arno

Re: AIX library issues

[David Edelsohn]

On Tue, Oct 25, 2011 at 4:15 AM, Arnaud Charlet <charlet@adacore.com> wrote:
>> I wonder if it might make sense to more strongly suggest to use GNU as
>> on AIX?  The install manual currently says
>>
>> The native @command{as} and @command{ld} are recommended for
>> bootstrapping
>> on AIX@.  The GNU Assembler, GNU Linker, and GNU Binutils version 2.20
>> is required to bootstrap on AIX 5@.  The native AIX tools do
>> interoperate with GCC@.
>>
>> What's the downside of not using the native AIX tools at all (assembler
>> and linker)?
>
> FWIW, we've recently made this choice/switch for GNAT at AdaCore, which
> allows us in particular to use dwarf-2/3 debug info.

Is AdaCore maintaining GNU Binutils on AIX?  I do not believe that
Binutils implements some toolchain changes to AIX 6.1 and AIX 7.1.

Using Binutils means someone keeping it up to date with AIX.  On the
other hand, if there is enough external interest in GNU Binutils, IBM
may lose control of the toolchain for its platform.

Thanks, David

Re: AIX library issues

[Arnaud Charlet]

> > FWIW, we've recently made this choice/switch for GNAT at AdaCore, which
> > allows us in particular to use dwarf-2/3 debug info.
> 
> Is AdaCore maintaining GNU Binutils on AIX?

We're "maintaining" it sufficiently for our needs, yes.

> I do not believe that
> Binutils implements some toolchain changes to AIX 6.1 and AIX 7.1.

That's quite possible. Currently we support AIX 5.2 and 5.3, so haven't
encountered AIX 6.x or 7.x specific issues.

Do you know if these toolchain changes are significant?

Arno

Re: AIX library issues

[David Edelsohn]

On Tue, Oct 25, 2011 at 10:26 AM, Arnaud Charlet <charlet@adacore.com> wrote:
>> > FWIW, we've recently made this choice/switch for GNAT at AdaCore, which
>> > allows us in particular to use dwarf-2/3 debug info.
>>
>> Is AdaCore maintaining GNU Binutils on AIX?
>
> We're "maintaining" it sufficiently for our needs, yes.
>
>> I do not believe that
>> Binutils implements some toolchain changes to AIX 6.1 and AIX 7.1.
>
> That's quite possible. Currently we support AIX 5.2 and 5.3, so haven't
> encountered AIX 6.x or 7.x specific issues.
>
> Do you know if these toolchain changes are significant?

AIX now supports DWARF debugging with XCOFF object files.  XCOFF also
has a new XCOFF_DEP_EXEMPT flag to override the default stack
execution disabled.  There are a lot of little changes for new AIX
features.

The bigger problem is GDB no longer is able to debug cc1plus on the
trunk and GCC now builds as C++ by default.

Thanks, David