libpthread vs libc dynamic link order

[Joakim Tjernlund]

> -----Original Message-----
> From: uclibc-bounces at uclibc.org 
> [mailto:uclibc-bounces at uclibc.org] On Behalf Of Bernd Schmidt
> Sent: den 21 juni 2007 16:25
> To: uClibc
> Subject: libpthread vs libc dynamic link order
> 
> In uClibc (when using linuxthreads.old), libc.so and 
> libpthread.so both 
> contain some functions with the same name, e.g. 
> _pthread_cleanup_push_defer.  The version in libc tries to 
> forward the 
> call to a function found in a table called 
> __libc_pthread_functions in 
> libpthread.  This table is initialized from an array called 
> __pthread_functions in pthread.c; this array contains a reference to 
> _pthread_cleanup_push_defer.
> 
> Depending on the order in which the dynamic linker sees libc.so and 
> libpthread.so, this table in libpthread can refer to either 
> the function 
> in libc or the one in libpthread.  We observed this with a Qt example 
> program: the executable was linked against libQtNetwork, 
> which in turn 
> was linked against libpthread, but the executable itself did not 
> reference libpthread.so.  As a result, the dynamic linker 
> ended up with 
> an order where it picked the functions in libc.so over the ones in 
> libpthread.so, and when the forwarder function in libc is called, it 
> keeps looking up itself in the table, and calling itself.
> 
> 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. Not sure what the deal is with _ and __ funs,
but there is probably a reason they aren't all __ or _ funs.

 Jocke