------- Comment #6 from dougkwan at google dot com 2007-11-02 02:02 -------
Richard,
I think I know what happened. Could you please do an
nm a.out|grep " pthread_"
or your executable and send that to me? It seems that we need to change glibc
unfortunately. Here is code at the end of libc/nptl/pthread_create.c:
/* If pthread_create is present, libgcc_eh.a and libsupc++.a expects some other
POSIX thread
functions to be present as well. */
PTHREAD_STATIC_FN_REQUIRE (pthread_mutex_lock)
PTHREAD_STATIC_FN_REQUIRE (pthread_mutex_unlock)
PTHREAD_STATIC_FN_REQUIRE (pthread_once)
PTHREAD_STATIC_FN_REQUIRE (pthread_cancel)
PTHREAD_STATIC_FN_REQUIRE (pthread_key_create)
PTHREAD_STATIC_FN_REQUIRE (pthread_setspecific)
PTHREAD_STATIC_FN_REQUIRE (pthread_getspecific)
When the linker sees pthread_create, it will also bring in pthread_mutex_lock
and pthread_mutex_unlock automatically but not pthread_cond_broadcast and
pthread_cond_wait. Those two symbols are defined as weak references so they
will remain NULL. Apparently the fix is to add dependency of
pthread_cond_broadcast and pthread_cond_wait into glibc.
A band-aid is removing the #define __GTHREAD_HAS_COND in gthr-posix*.h to
diasable the new code temporarily and util glibc is fixed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33960
