Linking problems with gcc 4.2.2 and AIX 5.2

Jonathan Saxton
Mon Jan 28 23:44:00 GMT 2008

Hmm, it is almost fair to say that top posting is encouraged by MS Outlook
... but scroll to the end of this for my follow-up.

-----Original Message-----
From: [] On
Behalf Of Thomas Mittelstaedt
Sent: 28 January, 2008 09:40
To: Jonathan Saxton
Subject: Re: Linking problems with gcc 4.2.2 and AIX 5.2

Have you tried to build with the system assembler and system linker? I 
recently built gcc 4.2.2 on aix 5.2 successfully with the following

export CONFIG_SHELL=/usr/local/bin/bash ## So configure scripts don't 
run so slowly
$ gcc -v
Using built-in specs.
Target: powerpc-ibm-aix5.2.0.0
Configured with: ../gcc-4.2.2/configure 
--enable-version-specific-runtime-libs --enable-static --enable-shared 
--enable-threads --with-as=/usr/bin/as --without-gnu-ld 
--with-ld=/usr/bin/ld --prefix=/opt/gcc-4.2.2 --disable-nls --with-pic 
--disable-symvers --enable-symvers=no --enable-languages=c,c++,objc
Thread model: aix
gcc version 4.2.2

-fno-implicit-templates' bootstrap

Jonathan Saxton schrieb:
> A newbie gcc builder here.
> I've found reports of similar problems from a year or so back but no real
> resolution so I have to ask again.
> Recently I used gcc 4.0.0 to compile gcc 4.2.2 on AIX 5.2.  Compiler seems
> to work fine until I go to link something, then I get some fairly basic
> things unresolved.

[Sample program deleted]

> The command "g++ -o demo422 demo422.cpp" yields six link errors:
> $ g++ -o demo422 demo422.cpp
> ld: 0711-317 ERROR: Undefined symbol: .std::basic_string<char,
> std::char_traits<char>, std::allocator<char> >::size() const
> ld: 0711-317 ERROR: Undefined symbol: .std::basic_string<char,
> std::char_traits<char>, std::allocator<char> >::operator[](unsigned long)
> const

[5 error messages deleted]

> Adding -Wl,-bnoquiet doesn't really give anything that seems particularly
> helpful (well, to me, anyway) but using the -v flag suggests that the
> correct libstdc++.a is being found and also shows the (rather minimal) way
> configured gcc 4.2.2 when I built it.
> $ g++ -v -o demo422 demo422.cpp
> Using built-in specs.
> Target: powerpc-ibm-aix5.2.0.0
> Configured with: /home.local/jsaxton/gcc-4.2.2/configure
> --prefix=/opt/freeware : (reconfigured)
> /home.local/jsaxton/gcc-4.2.2/configure --prefix=/opt/freeware
> --enable-languages=c,c++
> Thread model: aix
> gcc version 4.2.2
>  /opt/freeware/libexec/gcc/powerpc-ibm-aix5.2.0.0/4.2.2/cc1plus -quiet -v
> -D_ALL_SOURCE demo422.cpp -quiet -dumpbase demo422.cpp -auxbase demo422
> -version -o /tmp//ccPpunCt.s
> ignoring nonexistent directory
> aix5.2.0.0/include"
> #include "..." search starts here:
> #include <...> search starts here:
> 4.2.2
> 4.2.2/powerpc-ibm-aix5.2.0.0
> 4.2.2/backward
>  /usr/local/include
>  /opt/freeware/include
>  /opt/freeware/lib/gcc/powerpc-ibm-aix5.2.0.0/4.2.2/include
>  /usr/include
> End of search list.
> GNU C++ version 4.2.2 (powerpc-ibm-aix5.2.0.0)
>         compiled by GNU C version 4.2.2.
> GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=32768
> Compiler executable checksum: 757566dd4c47f91799c975df3ba00055
>  as -u -mppc -o /tmp//ccRMMUUA.o /tmp//ccPpunCt.s
>  /opt/freeware/libexec/gcc/powerpc-ibm-aix5.2.0.0/4.2.2/collect2
> -bpT:0x10000000 -bpD:0x20000000 -btextro -bnodelcsect -o demo422
> -L/opt/freeware/lib/gcc/powerpc-ibm-aix5.2.0.0/4.2.2
> -L/opt/freeware/lib/gcc/powerpc-ibm-aix5.2.0.0/4.2.2/../../..
> /tmp//ccRMMUUA.o -lstdc++ -lm -lgcc_s
> /opt/freeware/lib/gcc/powerpc-ibm-aix5.2.0.0/4.2.2/libgcc.a -lc -lgcc_s
> /opt/freeware/lib/gcc/powerpc-ibm-aix5.2.0.0/4.2.2/libgcc.a
> (At this point the error messages shown earlier are displayed so I didn't
> bother to include them again.)
> If my double-dot counting is correct, the library path devolves to
> /opt/freeware/lib and there are four libstc++.a files thereunder, all
> freshly created by the install.  I cannot see any trace of any library
> over from 4.0.0.
> 2008-01-25 16:15:01 nextferry:/opt/freeware/lib
> $ find . -name libstdc++.a
> ./pthread/ppc64/libstdc++.a
> ./pthread/libstdc++.a
> ./ppc64/libstdc++.a
> ./libstdc++.a
> I'm a bit stuck.
> If I really need to rebuild gcc with different configuration options then
> with a bit of work I can do that.  Meanwhile "which ld"  yields
> which is a symlink to the native AIX linker (/usr/ccs/buin/ld).  There is
> gcc version of ld anywhere.  It is my understanding that this is correct
> AIX 5.x.
> Advice eagerly sought.  I can generate the -bnoquiet output if needed but
> this is already a very long message.


Thanks for the response.  I had noticed your earlier posting of your build
configuration.  Of course that came the day AFTER I had gone through the
whole process without the benefit of prior experience.

I was hoping to avoid re-installing gcc 4.0.0 and rebuilding from scratch,
but if that is what I need to do then so be it.

I had noticed the problems with /bin/sh.  In my case it actually failed with
a segfault after about 11 hours trying to build libstdc++-v3. With bash the
same process took less than an hour and did not segfault.

I believe I was using the system ld since there was no gnu version of that
tool anywhere on the system.  However I did not specify those options in the
configuration.  My configuration options were very simple; I just specified
the output tree (--prefix=/opt/freeware) and (second time around) the
languages (c,c++).  I notice that you included objc.  Do you actually use
Objective-C or is it necessary for compiling and linking C++ programs?

I had also discovered the problem with the gnu version of as.  I got around
that by the simple expedient of deleting it and making it a symlink to the
AIX version.  That made the gcc 4.2.2 build work although it was probably
not as elegant as adding the config option.  In any case, there is no gnu
version of as anywhere so the 4.2.2 compiler is using the native version for
my little test program.

After writing all this I am wondering if it is really necessary to go all
the way back to 4.0.0 since I have not deleted the 4.2.2 build stages.

More information about the Gcc-help mailing list