This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2
- From: "redi at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 31 Jan 2012 00:01:41 +0000
- Subject: [Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2
- Auto-submitted: auto-generated
- References: <bug-51906-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906
--- Comment #24 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-01-31 00:01:41 UTC ---
That debug session still doesn't make much sense, are you debugging an
optimised executable? I don't need a more detailed trace, just one that
actually shows what happens! e.g. knowing what pthread_mutex_trylock returns
is necessary, knowing the details of what happens inside that function isn't
necessary.
What does this return?
#include <pthread.h>
struct mutex {
pthread_mutex_t m = PTHREAD_RECURSIVE_MUTEX_INITIALIZER;
};
int main()
{
mutex m;
return pthread_mutex_trylock(&m.m);
}
If the solution is simply to define _XOPEN_SOURCE then that should be done for
Lion, but a relevant maintainer for that target should make that decision.
libstdc++ relies on POSIX features so if they aren't correctly defined without
_XOPEN_SOURCE then that is needed (on GNU/Linux _GNU_SOURCE is always defined)