This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/33960] [4.3 Regression] r129030 breaks -fopenmp -static compile of tramp3d-v4
- From: "dougkwan at google dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 2 Nov 2007 02:02:41 -0000
- Subject: [Bug c++/33960] [4.3 Regression] r129030 breaks -fopenmp -static compile of tramp3d-v4
- References: <bug-33960-10053@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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