[Bug gold/10238] Gold linker does not resolve symbols using indirect dependencies

[ian at airs dot com]

------- Additional Comments From ian at airs dot com  2009-06-05 05:05 -------
I should say: thanks for the bug report.  I appreciate it.

gold is not intended to be a precise replacement for the GNU linker.  The GNU
linker has too much history and is the result of too many odd decisions (many
made by myself).  gold is intended to be be a 98% replacement, but there are a
number of known incompatibilities.  This is one of them.

That said, if there is a good reason that gold should implement this feature,
I'm willing to consider it.  But precise compatibility with the GNU linker is
not yet enough of a reason to convince me.

It's not correct that it doesn't matter which library the linker finds at link
time.  If the library has version information in it, then there can be trouble
if the dynamic linker finds a different library.  Also, if the symbol being
resolved is a data symbol, the size of the symbol will be copied into the
executable.  If a COPY reloc is created, and the size of the symbol does not
match the size of the symbol in the library found by the dynamic linker, the
program will fail at runtime.  These are uncommon issues, but real enough that
it's fairly important in practice that both linkers use the same search path.

Your script did not work for me until I added -Wl,-rpath,. to the GNU linker
command line.  I'm not sure why you didn't need that.

Do you happen to know why PurifyPlus uses this feature of the GNU linker?  It's
not a feature of other ELF linkers.

-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10238

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.