https://sourceware.org/bugzilla/show_bug.cgi?id=26103
--- Comment #5 from Alan Modra <amodra at gmail dot com> --- I still haven't managed to reproduce the problem, but your symbol dumps give a clue as to what is going on. [479](sec 0)(fl 0x00)(ty 20)(scl 69) (nx 1) 0x00000000 _ZSt7forwardIDnEOT_RNSt16remove_referenceIS1_E4typeE AUX indx 462 srch 1 The above symbol is storage class 105 (llvm-objdump in hex??) or C_NT_WEAK. The aux entry points at an alias; [462](sec 106)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000 .weak._ZSt7forwardIDnEOT_RNSt16remove_referenceIS1_E4typeE._ZStanSt12_Ios_IostateS_ This has ".weak." prepended and some other global symbol name appended, the idea being to make the alias unique to the object file. Which isn't very robust, and may result in multiple symbol definition errors. But that's not what you are seeing. Can you repeat your gdb debug session, going up from add_archive_element to coff_link_check_archive_element to see the symbol. Then put a watchpoint on h->type, running the link again to see changes in h->type. The one I'm interested in is a possible change from bfd_link_hash_defined back to bfd_link_hash undefined, and where that occurs in the source. You might need to rebuild binutils at a lower optimisation level than -O2 in order to be able to do this. -- You are receiving this mail because: You are on the CC list for the bug.
