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

[apratt at us dot ibm dot com]

------- Additional Comments From apratt at us dot ibm dot com  2009-10-13 00:27 
-------
It's the second one, with a variation. I wouldn't expect your second example to
link successfully as written. If you change it so main() calls both a() and b(),
it will link with today's GNU linker. That's because when liba comes in (thanks
to the call to a), the symbols from its DT_NEEDED libraries are also visible for
resolving symbols used in main(), like b. Not so with gold.

On the one hand you can say that a link line "should" express the direct,
first-order dependencies of the program being linked. But with today's GNU
linker, a project's link line does not have to do so. That's what's at issue.
Gold risks suffering upon release with this kind of review: "It's great but
there are a bunch of existing projects for which it doesn't work, so if you make
it your system linker you risk having to tinker with projects you download and
build."

Over time, I'm sure projects would adapt - at least, those which are being
maintained. But user resistance at first release could be a problem for
widespread adoption. Of course, whether that's a problem really depends on your
goals.

I'm going to stop advocating either way because I don't really have a dog in
this hunt. For our part, I'm sure we can make PurifyPlus work. I realize the
current GNU linker behavior is ill-specified and variable, and it's probably
hard to intentionally match any of the organically-evolved implementations. But
I would worry about having built-in barriers to adoption out of the gate. I hope
Ian can "collect real data rather than speculation" before the initial (wide)
release, and version 1.0 gets the kind of reception he and the other project
members desire.


-- 


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.