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