libpthread vs libc dynamic link order

Joakim Tjernlund joakim.tjernlund at transmode.se
Sun Jun 24 14:17:09 UTC 2007


 

> -----Original Message-----
> From: Bernd Schmidt [mailto:bernds_cb1 at t-online.de] 
> Sent: den 24 juni 2007 14:56
> To: Joakim Tjernlund
> Cc: 'uClibc'
> Subject: Re: libpthread vs libc dynamic link order
> 
> 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?

Well, I am no thread expert. Luckily I have avoided that pretty
much, but I think the general idea is that you should be able
to build libs that are thread aware. Suppose a lib needs
to lock some global data iff the lib is used in a threaded app.
Then you can use the mutex_lock funs in libc which pretty
much is a null op. If the app using the lib links in phread,
then these mutex_lock funs will be replaced by the one in pthread
automatically. 

> 
> 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.

I never got the hang of the hidden_{proto,def} stuff. I think these
are way overcomplex. I don't think this is the way either and
that you need a thread expert to make sense of all the details.

 Jocke





More information about the uClibc mailing list