[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2

["iains at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906

--- Comment #51 from Iain Sandoe <iains at gcc dot gnu.org> 2012-02-03 17:56:29 UTC ---
(In reply to comment #49)
> (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?

if you are relying on system features that are not the same on different
versions, then yes.

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

OK. I'd missed that - in which case no objection to the unconditional disable
from me.

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

Well, in this case you would bypass your test, but use the older header
(notwithstanding issues of run-time vs config time) - so, yes, I suppose it
would work in principle.