weak undefined symbols from early object files

[David Meggy <David dot Meggy at icron dot com>]

Hi all,

I'm looking at a linker issue, which I'd like to verify whether it is a bug, or intentional.

When I link my elf file, the linker is passed all the libraries to link against in order.? My first library consists of some debug functionality, to assist in debugging lower level libraries.? The lower libraries may or may not export debug information to the debug library.? The link line looks like "ld -o output.elf src1.o src2.o -ldebug -la -lb -lc -Tboard.ld"

The first library consists of a C file which contains

extern const void * liba_debug_info __attribute__ ((weak));
extern const void * libb_debug_info __attribute__ ((weak));
extern const void * libc_debug_info __attribute__ ((weak));
// and then references these weak undefined symbols (first checking if they are NULL or not)

The lower level libraries may or may not provide a symbol for those variables.

What I've found out is the linker seems to always leave the symbols as undefined, so the elf contains NULL values for them, even though there is a libb_debug_info defined in an object in libb.a.

This occurs on binutils 2.19, 2.20 (both ld and gold), and 2.20.1 (both ld and gold)

It is very obvious from the documentation that it is intended that a weak symbol is ignored if a normal symbol already exists, but googling references to the opposite order isn't turning much up.? I'd expect that if a weak symbol is defined (or undefined), and a library later provides a normal symbol, then the normal symbol would take precedence.? Especially in my case as I have an undefined weak symbol.? Is this correct?? If so I can file a bug report.

Thanks
David