https://sourceware.org/bugzilla/show_bug.cgi?id=21964
--- Comment #8 from Michael Matz <matz at suse dot de> --- You mean it shows an additional issue, I wasn't saying my patch is perfect, merely that it fixes my reported problem. I think it's the same reason of why the testcase ld-gc/pr20022 fails with the proposed patch. bfd_elf_define_start_stop doesn't want to create a __start symbol if there already exists a defined one in the hash table, even if that comes from a dynamic object. Normal symbols would have gone through _bfd_elf_merge_symbol, which would have overridden the definition from a dynamic object with the one from regular files if the latter has non-default visibility. But bfd_elf_define_start_stop simply gives up, doesn't create the proper local (hidden/protected whatever you want to call it) __start symbol and hence resolves regular refs against the one from the dynamic object (invalidly so). Looking at this, that ld-gc/pr20002 doesn't fail without the patch from comment #4 is a nice thing, but I think it succeeds for the wrong reasons. Something is fishy with how those start/stop symbols are created, IMHO. -- 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