------- Additional Comments From ian at airs dot com 2005-11-05 05:07 ------- Unfortunately it's too simple to allude to the historical handling of common symbols. In a.out linkers when a common symbol appears in an object, and the symbol is defined in an object in an archive, then the object in the archive is pulled into the link (actually this is somewhat target dependent--the SunOS linker would pull in definitions which were in the .data section but not ones which were in the .text sectin, assuming that a function could never merge with a common symbol).
Moreover, if a common symbol appears in an object, and the symbol is a common symbol in an object in an archive, then in an a.out linker the size of the common symbol is changed, but the object is *not* pulled into the link. This last behaviour is of course pretty crazy. But in general it isn't reasonable for the ELF ABI to claim that they just rely on historical behaviour for the definition of common symbols, because in fact ELF common symbols do not act like historical ones do. That said, I was never all that happy with this change, and I think the behaviour before the change was more coherent. But, unfortunately, given the way that system files and libraries are written, it is important that we be compatible with system linkers. You say the UnixWare linker acts differently. That suggests that we need to make this target dependent. This is precedent for this in the a.out linker, and the use of the common_skip_ar_aymbols field in struct bfd_link_info. -- http://sourceware.org/bugzilla/show_bug.cgi?id=1811 ------- 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
