Using GNU as, MIPSpro cc, and IRIX ld, the following error is encountered during the build: $ cd /opt/build $ gzip -dc gcc-4.0.2.tar.bz2 $ mkdir gcc-4.0.2-objdir $ cd gcc-4.0.2-objdir $ CC=cc /opt/build/gcc-4.0.2/configure --enable-shared --with-gnu-as \ --with-as=/opt/TWWfsw/gcc402/mips-sgi-irix6.5/bin/as \ --enable-languages="c,c++" ... $ gmake bootstrap ... /opt/fsw/bin/bash ../libtool --tag CXX --mode=link /opt/build/gcc-4.0.2-objdir/gcc/xgcc -shared-libgcc -B/opt/build/gcc-4.0.2-objdir/gcc/ -nostdinc++ -L/opt/build/gcc-4.0.2-objdir/mips-sgi-irix6.5/libstdc++-v3/src -L/opt/build/gcc-4.0.2-objdir/mips-sgi-irix6.5/libstdc++-v3/src/.libs -B/usr/local/mips-sgi-irix6.5/bin/ -B/usr/local/mips-sgi-irix6.5/lib/ -isystem /usr/local/mips-sgi-irix6.5/include -isystem /usr/local/mips-sgi-irix6.5/sys-include -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -o libstdc++.la -rpath /usr/local/lib/../lib32 -version-info 6:6:0 -lm bitmap_allocator.lo pool_allocator.lo ... ... /opt/build/gcc-4.0.2-objdir/gcc/xgcc -shared-libgcc -B/opt/build/gcc-4.0.2-objdir/gcc/ -nostdinc++ -L/opt/build/gcc-4.0.2-objdir/mips-sgi-irix6.5/libstdc++-v3/src -L/opt/build/gcc-4.0.2-objdir/mips-sgi-irix6.5/libstdc++-v3/src/.libs -B/usr/local/mips-sgi-irix6.5/bin/ -B/usr/local/mips-sgi-irix6.5/lib/ -isystem /usr/local/mips-sgi-irix6.5/include -isystem /usr/local/mips-sgi-irix6.5/sys-include -shared -nostdlib /opt/build/gcc-4.0.2-objdir/gcc/irix-crti.o /opt/build/gcc-4.0.2-objdir/gcc/crtbegin.o .libs/bitmap_allocator.o ... ld32: FATAL 2 : Internal: at ../../ld/section_type.c In load_info() unknown section type collect2: ld returned 1 exit status gmake[4]: *** [libstdc++.la] Error 1 gmake[4]: Leaving directory `/opt/build/gcc-4.0.2-objdir/mips-sgi-irix6.5/libstdc++-v3/src' Looks like an IRIX ld(1) bug.
BTW, the MIPSpro compiler is 7.4.3m and the build system is IRIX 6.5.26m.
Looking at the section headers for one of the object files: $ elfdump -h .libs/allocator-inst.o .libs/allocator-inst.o: **** SECTION HEADER TABLE **** [No] Type Addr Offset Size Name Link Info Adralgn Entsize Flags [1] 0x11 0 0x34 0x8 .group 43 0x25 0x4 0x4 0x00000000 [2] 0x11 0 0x3c 0x8 .group 43 0x26 0x4 0x4 0x00000000 ... [13] SHT_PROGBITS 0 0xa0 0 .text 0 0 0x10 0 0x00000006 ALLOC EXECINSTR [14] SHT_PROGBITS 0 0xa0 0 .data 0 0 0x10 0 0x00000003 WRITE ALLOC ... Notice for some of the section headers, we get numbers for the type (e.g. 0x11) rather than a name (SHT_PROGBITS). Is this the reason for the ld error? I'm thinking the section types in the elfdump -h output get converted to names for the types ld knows about and left as numbers otherwise. According to <elf.h>: #define SHT_NULL 0 /* sh_type */ #define SHT_PROGBITS 1 #define SHT_SYMTAB 2 #define SHT_STRTAB 3 #define SHT_RELA 4 #define SHT_HASH 5 #define SHT_DYNAMIC 6 #define SHT_NOTE 7 #define SHT_NOBITS 8 #define SHT_REL 9 #define SHT_SHLIB 10 #define SHT_DYNSYM 11 #define SHT_NUM 12 /* Number of sh_types, not an actual */ /* sh_type. */ /* SHT_NUM must be one greater than the ** highest sh_type value. */ I looked at .libs/allocator-inst.o from gcc-3.4.3 and didn't see the 0x11 section types.
This might be a GNU as bug. I'm going to ping the binutils folks.
Ok, not a binutils bug. Richard Sandiford <richard@codesourcery.com> provided the solution. If GNU as is used with GNU ld, COMDAT group should be supported on this platform. However, if GNU as is used with MIPSpro ld, COMDAT group should _not_ be used. The problem is that GNU as supports it but the MIPSpro linker does not. As the autoconf test only tests the compiler, GCC tries to use it. The current workaround is to set and export the following before 'make bootstrap': gcc_cv_as_comdat_group=no gcc_cv_as_comdat_group_percent=no
I'd like to either close this or change it to bootstrap, in the attempt to flag the attention of the top-level build people for this bug. I don't consider this a libstdc++ problem.....
(In reply to comment #5) > I'd like to either close this or change it to bootstrap, in the attempt to flag > the attention of the top-level build people for this bug. > > I don't consider this a libstdc++ problem..... Ok.
*** This bug has been marked as a duplicate of 26053 ***