http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375
--- Comment #14 from Dave Korn <davek at gcc dot gnu.org> 2010-12-02 08:52:20 UTC --- (In reply to comment #13) > > Yeh, precisely. The ironly file is a placeholder into which we put the > > symbols found in the lto symtab so that they can take part in the link and > > their resolutions be determined. We have no way of conveying any symbol > > type > > The error comes out after the lto1 invocation, so why the ironly section is > still around? > I would expect it to be discarded at that time and replaced by whatever > compiler > returns to you. It's the symbol from the ironly section that remains, and it gets discarded and replaced by the the symbol from the real object file by the linker multiple_definition callback hook when _bfd_generic_link_add_one_symbol is called to add the symbol from the real object file into the link hash table. Unfortunately, the elf linker has some additional checking that it does before calling that routine which preemptively complains about the multiple definition before the linker hook has a chance to replace the original ironly symbol by the new one.
