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. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils