[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/815] [C-api -> C++ lib] undefined symbol _Unwind*

From: amodra at bigpond dot net dot au
Subject: [Bug ld/815] [C-api -> C++ lib] undefined symbol _Unwind*
Date: 15 Apr 2005 02:35:44 -0000

------- Additional Comments From amodra at bigpond dot net dot au  2005-04-15 
02:35 -------
Ah!  Seeing address@hidden'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 

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



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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]