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