[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-07-27 18:24 
-------
Reviewing this bug (due to this weekend's new comment), I notice I never
answered the question about why PurifyPlus is using this indirect-link feature.

I spoke with the developer who did the original Linux port, and it sounds like
this amounted to a workaround for a bug in the stock Linux ld. The
strong-vs-weak symbol resolution wasn't working as expected. Starting with
RedHad 8's libc-2.3.2, some versioned symbols like pthread_cond_wait were made
"strong hidden" but the linker was still picking a "weak hidden" symbol from
another library instead. (The "other library" is a stub library we provide in
case you don't link with libthread.) The choice appeared to depend on the order
that tables were getting built inside the linker rather than the strong-vs-weak
attributes of the symbols. The only way we found of getting the linker to pick
the right symbols was to make it see the instrumented libc indirectly, not on
the command line. 

We've been doing it that way ever since, with no reason to re-investigate the
issue or change the solution, even though much has changed in Linux libraries
(and probably in the linker) since then. 

This is not to say that there are no other possible solutions, only to explain
why we started using the indirect symbol resolution feature at all.

-- 


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.