common symbols in archive symbol table

[Roland McGrath <roland at frob dot com>]

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.