This problems occurs on targets using an a.out format by default, while having support for ELF format. Such targets include i386-pc-netbsdaout and m68k-netbsdaout.
Basically, in certain conditions, a "stab warning" in an object file cause ld to discard all the symbols defined in that object. When there is no stab warning, the testcases described here works fine. $ cat a.s .extern _f jmp _f $ cat b.s .stabs "a linker warning",30,0,0,0 .stabs "_f",1,0,0,0 .globl _f _f: ret $ as a.s -o a.o # file format a.out-i386-netbsd $ as b.s -o b.o # file format a.out-i386-netbsd $ ld a.o b.o -o ab # file format a.out-i386-netbsd a.o:a.o:(.text+0x1): warning: a linker warning We can see here that everything uses the a.out file format, and everything works as expected. The problem occurs if a.o is converted to ELF. $ objcopy a.o a-elf.o -O elf32-i386 BFD: a-elf.o: warning: allocated section `.text' not in segment $ ld a-elf.o b.o -o ab a-elf.o:(.text+0x1): warning: a linker warning a-elf.o:(.text+0x1): undefined reference to `_f' The link fails because the symbol _f is not found, however it is still in the b.o file. $ binutils-2.18-netbsd.obj/binutils/objdump -t b.o b.o: file format a.out-i386-netbsd SYMBOL TABLE: 00000000 W d *ABS* 0000 00 1e a linker warning 00000000 g *ABS* 0000 00 03 _f 00000000 g .text 0000 00 05 _f Further strangeness comes if we convert a.o into ELF, too. $ objcopy a.o a-elf.o -O elf32-i386 BFD: a-elf.o: warning: allocated section `.text' not in segment $ ld a-elf.o b-elf.o -o ab b-elf.o: In function `_f': (.text+0x0): multiple definition of `_f' -- Summary: stab warnings cause linker errors Product: binutils Version: 2.18 Status: NEW Severity: normal Priority: P2 Component: ld AssignedTo: unassigned at sources dot redhat dot com ReportedBy: vincent dot riviere at freesbee dot fr CC: bug-binutils at gnu dot org GCC target triplet: i386-pc-netbsdaout http://sourceware.org/bugzilla/show_bug.cgi?id=6478 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils