static linking for pthreads in nptl branch?

Carmelo AMOROSO carmelo.amoroso at st.com
Tue Sep 2 14:40:40 UTC 2008


Chris Metcalf wrote:
> On 9/2/2008 10:06 AM, Carmelo AMOROSO wrote:
>> I had to read it more carefully.. you are right, and yes, probably the
>> issue you were referring to about static link and pthread was raised
>> by me in the past.
>> It was related to opendir function that is the only function within libc
>> that calls pthread_mutex_init, and yes, when statically linked, even
>> if using -lpthread, it was bind to the libc stub. At that time I fixed
>> opendir by adding a memset to clear the lock data.
>> (see http://www.uclibc.org/cgi-bin/viewcvs.cgi?rev=20625&view=rev)
> 
> Since I just made that example up, it's funny that it was a real problem :-)
> 
:-)
>> What about adding PTHREAD_STATIC_FN_REQUIRE (pthread_mutex_init)
>> in nptl/init.c ? were you thinking to this with the word 'register'.
>> I did not test it, but it may be sufficient.
> 
> I had been thinking of just using the same shared model of "struct
> pthread_functions", but that's probably overkill, since it would bring
> in all of libpthread.a even if the application only used a few
> functions.  So perhaps just the extra PTHREAD_STATIC_FN_REQUIRE is the
> right approach.  It also avoids the scary assumption that
> PTHREAD_MUTEX_INITIALIZER is also all-zeroes on all platforms.
> 
Well, I've tried it using the old test case I had for the opendir 
problem, and with this fix pthread_mutex_init, in a static 
multi-threaded app, is now linked from libptrhead.a instead of libc.a 
(weaks.o).
If the app were single-threaded (-> pthread_create not called), then it 
would correctly resolved into the empty stub provided ad hoc by weaks.o.

Please, may you try with your application and see if it works as well ?

Carmelo




More information about the uClibc mailing list