------- Additional Comments From amodra at bigpond dot net dot au 2005-04-15 02:35 ------- Ah! Seeing [EMAIL PROTECTED]'s u.undef.next link back to itself was the clue I needed. u.undef.next is used as a list pointer, and also as a marker to say that a symbol has been referenced. As a marker, u.undef.next is set to point to the symbol itself, so obviously can't be on the list and thus won't be fixed by bfd_link_repair_undef_list.
Hmm, but just fixing u.undef.next might be papering over another problem, as it isn't exactly clear how u.undef.next is being set like this. I suspect the following scenario: a) pthread_mutex_init is defined in one shared lib and referenced by another, which would leave u.undef.next pointing back to the sym b) an as-needed lib is loaded which also defines pthread_mutex_init. There is a hack in _bfd_elf_merge_symbol around line 1177 of elflink.c to stop multiple symbol definition errors when two shared libs define a sym. Unfortunately, this will result in the symbol being marked as defined in the as-needed lib. c) The as-needed lib doesn't satisfy any undefined syms in regular object files, so elf_smash_syms is called to remove syms defined in the library. This interacts with the above mentioned hack, and results in the symbol being undefined. To confirm this, would you please give the result from readelf -sD lib.so | grep pthread_mutex_init for each shared lib involved in the link. It might pay to add -Wl,--verbose to options passed to libtool so that you see the real list of libs involved in the link. -- http://sources.redhat.com/bugzilla/show_bug.cgi?id=815 ------- 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
