https://sourceware.org/bugzilla/show_bug.cgi?id=26103
Alan Modra <amodra at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2020-06-14
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Assignee|unassigned at sourceware dot org |amodra at gmail dot com
--- Comment #8 from Alan Modra <amodra at gmail dot com> ---
> I set the watchpoint on h->type for the weak symbol and it only gets set to
> bfd_link_hash_undefined once
OK, so that would seem to mean we don't have the class of linker bug that
caused pr24567.
Next theory: The .weak.* symbol (which isn't weak BTW) is defined in a
LINK_ONCE_DISCARD section, and the section is discarded due to some other copy
of the section being linked before ios.o is linked. You can check that this
might be so by inspecting your ios.o with objdump -th to see whether the weak
symbol section (index 169 according to the dump you attached) is
LINK_ONCE_DISCARD. That would make the .weak.* symbol bfd_link_hash_undefined,
cofflink.c:314.
Then, when the libstdc++ archive is searched again after loading the lto output
object file, ios.o is seen as defining this undefined symbol. Oops, we load
ios.o again.
The good news is that I managed to create a relatively simple testcase that
doesn't require LTO, and that fails on ELF targets.
--
You are receiving this mail because:
You are on the CC list for the bug.
