I have tried building the compiler from scratch with the options suggested by Thomas. I have also tried a few variations, like leaving out the 'ld' specifications. In all cases I end up with a C++ compiler which does not link anything which uses STL. Internal templates are fine. The linker just does not like libstdc++. It seems to me that the problem may be the linker rather than the compiler. The compiler can build itself. Here is what I see on AIX 5.2 $ ls -l `which ld` lrwxrwxrwx 1 bin bin 15 1970-01-03 09:24 /usr/bin/ld -> /usr/ccs/bin/ld $ ls -l /usr/ccs/bin/ld -r-xr-xr-x 1 bin bin 32614 2004-05-14 04:36 /usr/ccs/bin/ld This is quite different from the one on our AIX 5.3 box -r-xr-xr-x 1 bin bin 38026 2006-04-21 14:48 /usr/ccs/bin/ld Doing a 'strings' dump on the two programs produces radically different results. The output from the first one on the AIX 5.2 box is quite large and contains lots of cleartext error messages. Conversely the 5.3 version yields a very short strings dump: 'strings' dump of AIX 5.3 ld ---------------------------- @(#)61 1.15 src/bos/usr/ccs/lib/libc/__threads_init.c, libcthrd, bos53H, h2006_10B1 3/5/06 16:44:58 @(#)23 1.65.1.5 src/bos/usr/ccs/bin/ld/ld.c, cmdld, bos53H, h2005_38C4 9/21/05 14:43:40 The corresponding portion of the large 5.2 strings output shows much older timestamps, consistent with that of the file itself. Partial 'strings' dump of AIX 5.2 ld ------------------------------------ @(#)61 1.14 src/bos/usr/ccs/lib/libc/__threads_init.c, libcthrd, bos520 7/11/00 12:04:14 @(#)23 1.66 src/bos/usr/ccs/bin/ld/ld.c, cmdld, bos52F, f2003_52A8 12/9/03 18:31:42 So I have at least two questions: 1. Should the old ld work anyway or do I need to update? 2. Is it possible to use gnu ld instead? (I haven't succeeded so far but I haven't tried very hard.) There may be more which follow from these. If I need to update then where would I find more recent versions? IBM website somewhere? -----Original Message----- From: gcc-help-owner@xxxxxxxxxxx [mailto:gcc-help-owner@xxxxxxxxxxx] On Behalf Of Jonathan Saxton Sent: 28 January, 2008 10:24 To: 'Thomas Mittelstaedt' Cc: gcc-help@xxxxxxxxxxx Subject: RE: Linking problems with gcc 4.2.2 and AIX 5.2 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: gcc-help-owner@xxxxxxxxxxx [mailto:gcc-help-owner@xxxxxxxxxxx] On Behalf Of Thomas Mittelstaedt Sent: 28 January, 2008 09:40 To: Jonathan Saxton Cc: gcc-help@xxxxxxxxxxx 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 configuration: 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 make CFLAGS='-O' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -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 STL > 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 I > 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 > "/opt/freeware/lib/gcc/powerpc-ibm-aix5.2.0.0/4.2.2/../../../../powerpc-ibm- > aix5.2.0.0/include" > #include "..." search starts here: > #include <...> search starts here: > /opt/freeware/lib/gcc/powerpc-ibm-aix5.2.0.0/4.2.2/../../../../include/c++/ > 4.2.2 > /opt/freeware/lib/gcc/powerpc-ibm-aix5.2.0.0/4.2.2/../../../../include/c++/ > 4.2.2/powerpc-ibm-aix5.2.0.0 > /opt/freeware/lib/gcc/powerpc-ibm-aix5.2.0.0/4.2.2/../../../../include/c++/ > 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 /lib/crt0.o > -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 left > 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 /usr/lbin/ld > which is a symlink to the native AIX linker (/usr/ccs/buin/ld). There is no > gcc version of ld anywhere. It is my understanding that this is correct for > AIX 5.x. > > Advice eagerly sought. I can generate the -bnoquiet output if needed but > this is already a very long message. Thomas: 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.
