static linking for pthreads in nptl branch?

[Carmelo Amoroso]

Chris Metcalf wrote:
> On 9/1/2008 2:51 AM, Carmelo AMOROSO wrote:
>> Chris Metcalf wrote:
>>> I seem to recall seeing some comment somewhere that static linking
>>> didn't work with pthread programs in the NPTL branch.  
>> No, there were bugs in the past but all fixed. We use nptl branch for
>> sh4 statically linked too... unless I did not push back these fix to
>> the SVN nptl branch, it sould work fine as well.
>> Let me find where/when I fixed this for sh.
> 
> It looks like my real problem was specific to some changes I made in our
> malloc.  We use the "mspace" malloc that is in later versions of Doug
> Lea's malloc, and one thing we do for performance is to give each thread
> its own mspace arena for allocation.  To make this fast for
> single-threaded programs we have a stub pthread_mspace() routine in libc
> and the real one in libpthread.  But if it's only referenced from libc
> (from malloc), then when a static link is done, we end up getting the
> single-threaded version from libc instead of the multi-threaded version
> in libpthread.  (Of course it works fine with shared objects.)
> 
> For now I'm fixing this by adding a dummy reference to pthread_mspace
> from nptl/init.c so it always gets resolved early enough in the static
> link process.  It seems like any pthread symbols not explicitly
> mentioned in nptl/pthread_create.c would have this problem too, though:
> for example, if you had a function in libc that wanted to be thread-safe
> when linked with -pthread and so called pthread_mutex_init() to set up a
> mutex in malloc'ed memory (for example), it would actually end up
> getting the libc version of pthread_mutex_init() when linked
> statically.  The libpthread versions of pthread_mutex_lock() and unlock
> are linked in properly since they're referenced in pthread_create().
> 
> I suspect the solution to all of this is to make sure to always
> "register" the correct function pointers for the whole API when
> libpthread's initialization code is called, so that the libc versions
> always end up doing a lookup on the registered function pointer and
> calling that, even with static linking.
> 

Hi Chris,
I understand your point, but can we say that we are building
a multi-threaded application if we don't call pthread_create
(that means linking pthread_create.o) ?

I think that you should define your stub for mspace as weak,
and, for the static case, call it by guarding against NULL...
if I've understood it correctly.

Cheers,
Carmelo