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