static linking for pthreads in nptl branch?
Chris Metcalf
cmetcalf at tilera.com
Wed Sep 3 17:56:07 UTC 2008
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.
--
Chris Metcalf, Tilera Corp.
http://www.tilera.com
More information about the uClibc
mailing list