public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2 Date: Fri, 03 Feb 2012 17:51:00 -0000 [thread overview] Message-ID: <bug-51906-4-1IKdtEUvI7@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-51906-4@http.gcc.gnu.org/bugzilla/> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906 --- Comment #49 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-02-03 17:50:07 UTC --- (In reply to comment #46) > (In reply to comment #45) > > Then I think we have to disable __GTHREAD_RECURSIVE_MUTEX_INIT unconditionally > > on darwin. > > I hope not. > putting -mmacosx-version-min=10.6 - will cause the macro value to be 1060 - so > defeating it. One would not expect it to run on 10.7. So using -mmacosx-version-min=10.6 without also using the 10.6 SDK is pilot error? But if I understand correctly, 10.6 didn't define PTHREAD_MUTEX_RECURSIVE_INITIALIZER anyway, so using the 10.6 SDK would cause it to be undefined, so why not just disable __GTHREAD_RECURSIVE_MUTEX_INIT unconditionally? The only system that defines it (10.7) can't use it. > If one puts -mmacosx-version-min=10.6 and sysroots to the 10.6 SDK - *and* > then transfers the executable to a 10.6 system - then that should work. If > not, then I agree. Presumably it doesn't even need to be transferred to a 10.6 system, using the 10.6 SDK should mean the headers don't have the static initializer, so the pthread_mutex_init_function() will always be used to create a recursive mutex, and Greg says that works on 10.7
next prev parent reply other threads:[~2012-02-03 17:51 UTC|newest] Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-01-19 20:16 [Bug libstdc++/51906] New: " howarth at nitro dot med.uc.edu 2012-01-19 20:21 ` [Bug libstdc++/51906] " redi at gcc dot gnu.org 2012-01-19 20:28 ` iains at gcc dot gnu.org 2012-01-19 20:43 ` howarth at nitro dot med.uc.edu 2012-01-19 20:49 ` dominiq at lps dot ens.fr 2012-01-19 21:59 ` redi at gcc dot gnu.org 2012-01-20 14:41 ` howarth at nitro dot med.uc.edu 2012-01-21 22:32 ` howarth at nitro dot med.uc.edu 2012-01-27 18:49 ` howarth at nitro dot med.uc.edu 2012-01-28 16:58 ` howarth at nitro dot med.uc.edu 2012-01-28 17:19 ` howarth at nitro dot med.uc.edu 2012-01-28 17:40 ` howarth at nitro dot med.uc.edu 2012-01-28 17:40 ` howarth at nitro dot med.uc.edu 2012-01-28 19:22 ` redi at gcc dot gnu.org 2012-01-28 23:07 ` howarth at nitro dot med.uc.edu 2012-01-28 23:44 ` howarth at nitro dot med.uc.edu 2012-01-29 1:28 ` redi at gcc dot gnu.org 2012-01-29 1:45 ` redi at gcc dot gnu.org 2012-01-29 17:04 ` howarth at nitro dot med.uc.edu 2012-01-29 17:19 ` iains at gcc dot gnu.org 2012-01-29 17:25 ` howarth at nitro dot med.uc.edu 2012-01-29 23:02 ` redi at gcc dot gnu.org 2012-01-30 15:36 ` howarth at nitro dot med.uc.edu 2012-01-30 18:50 ` howarth at nitro dot med.uc.edu 2012-01-31 1:18 ` redi at gcc dot gnu.org 2012-01-31 2:26 ` howarth at nitro dot med.uc.edu 2012-01-31 3:34 ` howarth at nitro dot med.uc.edu 2012-01-31 3:36 ` redi at gcc dot gnu.org 2012-01-31 3:36 ` howarth at nitro dot med.uc.edu 2012-01-31 3:37 ` redi at gcc dot gnu.org 2012-01-31 3:38 ` howarth at nitro dot med.uc.edu 2012-01-31 12:29 ` redi at gcc dot gnu.org 2012-01-31 15:51 ` howarth at nitro dot med.uc.edu 2012-01-31 15:57 ` redi at gcc dot gnu.org 2012-02-01 11:01 ` redi at gcc dot gnu.org 2012-02-03 1:46 ` redi at gcc dot gnu.org 2012-02-03 2:16 ` howarth at nitro dot med.uc.edu 2012-02-03 2:40 ` howarth at nitro dot med.uc.edu 2012-02-03 8:23 ` iains at gcc dot gnu.org 2012-02-03 8:46 ` redi at gcc dot gnu.org 2012-02-03 9:05 ` iains at gcc dot gnu.org 2012-02-03 9:18 ` redi at gcc dot gnu.org 2012-02-03 17:01 ` howarth at nitro dot med.uc.edu 2012-02-03 17:15 ` iains at gcc dot gnu.org 2012-02-03 17:17 ` redi at gcc dot gnu.org 2012-02-03 17:28 ` iains at gcc dot gnu.org 2012-02-03 17:39 ` howarth at nitro dot med.uc.edu 2012-02-03 17:46 ` howarth at nitro dot med.uc.edu 2012-02-03 17:51 ` redi at gcc dot gnu.org [this message] 2012-02-03 17:53 ` redi at gcc dot gnu.org 2012-02-03 17:57 ` iains at gcc dot gnu.org 2012-02-03 20:45 ` mikestump at comcast dot net 2012-02-04 13:39 ` redi at gcc dot gnu.org 2012-02-07 9:21 ` redi at gcc dot gnu.org 2012-02-07 9:23 ` redi at gcc dot gnu.org 2012-02-07 18:35 ` howarth at nitro dot med.uc.edu 2022-12-04 14:56 ` cvs-commit at gcc dot gnu.org 2024-04-18 14:41 ` cvs-commit at gcc dot gnu.org 2024-04-24 18:38 ` cvs-commit at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-51906-4-1IKdtEUvI7@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).