This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/33960] [4.3 Regression] r129030 breaks -fopenmp -static compile of tramp3d-v4



------- 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]