an ld problem?

I'm trying to compile egcs-1.0.2-9 on a Cobalt (mipsel) box. During the libstdc++ build I we have the following:

compile string:
/home/src/redhat/BUILD/egcs-1.0.2/obj-mipsel-linux/gcc/xgcc -B/home/src/redhat/BUILD/egcs-1.0.2/obj-mipsel-linux/gcc/ -O2 -fno-implicit-templates -Wl,-soname,libstdc++.so.2.8 -shared -o libstdc++.so.2.8.0 cat piclist -lm

result:
collect2: ld terminated with signal 6 [Aborted], core dumped

I have traced it through ld to this point: (elf32-mips.c : line 1526)

                          asection *osec;

                          osec = sec->output_section;
                          indx = elf_section_data (osec)->dynindx;
                          if (indx == 0)
                            abort ();

where it aborts. I am a bit bewildered. Anyone have any ideas to offer? Help?

Tim

I cheated; we currently ship only with a static libstdc++. We've got a fix for one of the many libbfd coredump bugs in elf32-mips.c in our patchset of ftp.linux.sgi.com. I think it won't cure this particular case, however.

Ralf

I'm calling in for help on the solution now.

The problem occurs when a segment is found that is not a known name, libbfd abort()s in mips_elf_relocate_section(). In the case of the egcs libstdc++ link the segments in question are : ".dtors" and ".gcc_except_table". I assume since .dtors is trouble, so will .ctors be.

If I add .dtors and .gcc_except_table to mips_elf_dynsym_sec_names[] in ${binutils_src_path}/bfd/elf32-mips.c and rebuild libbfd - ld no longer gets an abort() when compiling the file in question. I'm pretty sure this is NOT the right solution. There is also a table of sections in ${binutils_src_path}/bfd/syms.c. What is the "right" solution, and what other sections can exist that bfd doesn't know about?

Someone with a bit more experience inside libbfd - please help? :)

Tim

I think that already having a list of section names for that purpose is an error. Current libbfd doesn't rely on it anymore. Guess it's time to bite the bullet and try to rebuild the entire system just using binutils-current from Cygnus CVS. Binutils, born to be fixed ...

There is another bug in libbfd where section->owner is NULL which makes the linker do the segv boogy. It's being trigger by the linker options ``-lm -lieee'' when linking arbitrary code using the native linker. I didn't research that case further because I got detracted into GDB debugging when GDB started crashing while I was investigating that case ...

Ralf