handling "-lc -lpthread" for shared objects in uClibc

[Chris Metcalf]

I'm puzzled by something I'm seeing, and wondering if the simple fix is
wrong.  I'm using the uClibc-nptl branch as of change 22990.

The scenario is that a user links "-lc -pthread", and thus symbols are
resolved from libc before libpthread.  (A similar scenario is that a
user links with only "-lrt", for example, and thus gets "-lrt -lc" from
the linker, and the loader brings in libpthread afterwards to resolve
the dependency from librt.)

Now this is meant to be handled by the whole forwarding dance.  libc
links in forward.c from libpthread/nptl to define, e.g.,
__pthread_mutex_lock(), which checks a structure full of pointers, each
one pointing either to the "real" function, or NULL, so the forwarding
function can either forward properly, or else return a dummy value. 
When libpthread initializes, __pthread_initialize_minimal_internal()
copies a structure full of "real" function pointers into libc's structure.

But where this seems to go off the rails is that libpthread's structure
is full of pointers to __pthread_mutex_lock (etc.), which the loader
simply resolves to the first such symbol in the search path, namely...
the forwarding version in libc.  So that function ends up calling itself
in a loop forever.

One "obvious" solution would be to use -Bsymbolic.  This will bind the
references from within libpthread to libpthread symbols directly,
without using the loader to look them up.  Unfortunately this will break
references to global data like stdin, optind, etc., so is probably not
an option.

However, it seems like we should be able to use the libc_hidden_def
mechanism on the libpthread side to define and reference these
variables.  That will give us "-Bsymbolic" semantics for those functions
from within libpthread, but still allow libc to call directly to them
when things are linked normally with "-lpthread -lc".  I'll go ahead and
implement and test this solution.

Perhaps the tool chain on my architecture is broken, and most folks
normally get the "right" behavior by default somehow?  I suspect I'm
confused. :-)

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com