libpthread vs libc dynamic link order

[Bernd Schmidt]

Joakim Tjernlund wrote:
>> Is there a reason the forwarding functions in libc are 
>> visible to other 
>> shared libraries - it seems to me they are just for libc 
>> internal use? 
>> If not, the patch below seems to fix the problem here.  Any 
>> other ideas?
> 
> No other ideas, can't see a reason to export _X
> functions, but your patch hides all non _X funs too and 
> that looks wrong.

How so?  Why would anything want to access these libc forwader functions 
instead of the ones in libpthread?

Anyhow, plan b is to make sure the table in pthread.c refers only to 
hidden libpthread-internal functions.  That's done by the following patch.

Unfortunately, it's all a bit inconsistent.  The pthread_mutex functions 
already have private versions prefixed with __.  For most of the others, 
I've used libpthread_hidden_{proto,def} to create internal symbols; this 
however did not work for _pthread_cleanup_push_defer and 
_pthread_cleanup_pop_restore - it interfered with the weak stuff from 
libc-lock.h.  The latter file is probably more complex than necessary in 
uClibc, as we don't seem to use any of the libc_*_lock functions (should 
we?).  I've just created another name for these two functions with a 
strong alias.


Bernd
-- 
This footer brought to you by insane German lawmakers.
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: hide-symbols.diff
Url: http://lists.busybox.net/pipermail/uclibc/attachments/20070624/dc858a35/attachment-0002.diff