[Bug gold/23411] Different behavior when linking common symbol statically or to shared object

[amonakov at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=23411

--- Comment #9 from Alexander Monakov <amonakov at gmail dot com> ---
(In reply to Cary Coutant from comment #8)
>  Is that a problem we really need to worry
> about? The only real issue with including an otherwise-unneeded object
> is the potential violation of the language's namespace pollution rules
> (see below).

The reason it's being reported now is complications with plugin interaction.
Recently, GCC strengthened internal consistency checks for LTO symbol
resolution, and (combined with arguably poor choices for statuses reported for
symbols coming from unused members) they fail when such unpacked-but-unused
archive members get involved:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86490

I'm chiming in because I've been working on a third party (i.e. non-GCC,
non-LLVM) linker plugin recently, and this ld.bfd-specific behavior was
completely unexpected and cost some time. The ELF specification does not allow
this, the other docs I consulted did not mention it, and the way ar index is
built suggests common status is irrelevant for extraction (otherwise the index
would include the common flag).

If the BFD behavior is really intended, can at least the documentation please
be improved to explain that? And what would really help is a dedicated plugin
API entrypoint to allow the linker ask the plugin, "does IR in this file
provide a strong definition for any currently common symbol in this array:
["foo", "bar", ...]?"

-- 
You are receiving this mail because:
You are on the CC list for the bug.