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. -- Chris Metcalf, Tilera Corp. http://www.tilera.com _______________________________________________ uClibc mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/uclibc
