common symbols in archive symbol table
Roland McGrath
roland@frob.com
Fri Dec 10 11:49:00 GMT 1999
This seems to be related to the discussion going on lately between Ian and
Nick, but I'm not sure exactly what the state of that is and how this fits in.
I am using sourceware binutils as of today, configured with:
--host=i586-linux --target=arm-elf --enable-targets=arm-netbsd
I am using the arm-elf target. What I am observing is that a common
definition does not appear to make it into an archive symbol table,
and is therefore not found by the linker. This is different from the
behavior I have always seen on x86/ELF, but I haven't built the current
binutils for that target to compare today.
In my example I have a source file containing just "char **environ;".
This produces:
libc/environ.o: file format elf32-littlearm
SYMBOL TABLE:
00000000 l df *ABS* 00000000 environ.c
00000000 l d .text 00000000
00000000 l d .data 00000000
00000000 l d .bss 00000000
00000000 l .text 00000000 .gcc2_compiled.
00000000 l d .debug_abbrev 00000000
00000000 l d .debug_info 00000000
00000000 l d .debug_line 00000000
00000000 l d .debug_pubnames 00000000
00000004 O *COM* 00000004 environ
This object file then goes into a library, and I try to link against that
library, with another object that has a reference to `environ'. This
common definition in the archive is the only occurrence of `environ' in the
link, except as an undefined symbol.
The symptom is an undefined symbol error for environ. Using the ultimate
object-file examination tool Emacs, I can see that the library archive's
string table does not include the string `environ' at all.
(Is there a way to make objdump show you the archive's symbol table?)
Since this kind of usage has always worked in the past, methink this is a
binutils bug.
More information about the Binutils
mailing list