------- 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. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
