[Bug gold/21074] [2.28 Regression] bfd ld stumbles over duplicated symbols generated by gold

[ccoutant at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=21074

--- Comment #8 from Cary Coutant <ccoutant at gmail dot com> ---
> > Something is missing from this test case, I think. It links fine with gold,
> > and no duplicate symbols are generated.
> 
> That's strange - the test case works for me.  (Note- you need to use the bfd
> linker to link the test case not gold).
> 
> > In the problem description, your
> > __bss_start symbols have a Qt_5 version on them, but when I link your test
> > case, I don't see any versions on those symbols.

Well, in that case, I'm confused. I thought this was a test case to demonstrate
the bug in gold, not the one in ld.

Can I get a test case that demonstrates the problem in gold?

> Try:
> 
>   $ readelf --syms libapt-pkg.so.5.0  | grep bss_start
>   963: 00000000003b14a0     0 NOTYPE  GLOBAL DEFAULT 25
> __bss_start@@APTPKG_5.0
> 
> I do not know how GOLD resolves these symbol version conflicts.  Maybe it
> converts them into absolute symbols first ?

Sorry, I don't really know what you're referring to as version conflicts. And I
see only one copy of the symbol there. Where are the duplicate symbol messages
coming from? This sounds like it may really be just an ld bug.

> Actually it is fine with duplicate absolute symbols that *have the same
> value*.
> Which makes sense really.  Such symbols are just copies of each other. 
> Redundant perhaps, but not really a cause for failing to link. 

Why should duplicate absolute symbols be treated any differently from duplicate
relative symbols? The same argument you use that they're just copies of each
other applies to relative symbols with the same section and value.

-cary

-- 
You are receiving this mail because:
You are on the CC list for the bug.