static linking for pthreads in nptl branch?

[Carmelo AMOROSO]

Chris Metcalf wrote:
> On 9/2/2008 10:25 AM, 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.
>>   
> 
> I think we also need to add
> 
> /* Used by __UCLIBC_MUTEX_LOCK for the libc locking code. */
> PTHREAD_STATIC_FN_REQUIRE (_pthread_cleanup_pop_restore)
> PTHREAD_STATIC_FN_REQUIRE (_pthread_cleanup_push_defer)
> 
> in pthread_create.c to avoid getting the stub versions.
> 
Yes, I've already add this into my working dir. It's on the way for svn too.

Carmelo