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 _______________________________________________ uClibc mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/uclibc
