This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [PATCH] revised fix for nanosleep check in GLIBCXX_ENABLE_LIBSTDCXX_TIME for darwin
- From: Jack Howarth <howarth at bromo dot med dot uc dot edu>
- To: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- Cc: libstdc++ at gcc dot gnu dot org, mikestump at comcast dot net, iain at codesourcery dot com, paoauto-logoutoracle dot com at bromo dot med dot uc dot edu, gcc-patches at gcc dot gnu dot org
- Date: Tue, 9 Oct 2012 09:11:44 -0400
- Subject: Re: [PATCH] revised fix for nanosleep check in GLIBCXX_ENABLE_LIBSTDCXX_TIME for darwin
- References: <20121009003921.GA25678@bromo.med.uc.edu> <CAH6eHdTxsSB-ZFRerUHe-F2P2BURM4LqAz-6MwdTcaM5C9adwA@mail.gmail.com>
On Tue, Oct 09, 2012 at 09:21:25AM +0100, Jonathan Wakely wrote:
> On 9 October 2012 01:39, Jack Howarth wrote:
> > The --enable-libstdcxx-time=yes configure option fails to validate the
> > presence of a usable nanosleep() call on darwin due to its use of pre-2008
> > POSIX timers. As both nanosleep() and sched_yield() have always been available
> > on darwin, the attached patch simply defines _GLIBCXX_USE_NANOSLEEP and
> > _GLIBCXX_USE_SCHED_YIELD in config/os/bsd/darwin/os_defines.h. This also has
> > the advantage of effectively making --enable-libstdcxx-time=yes the default
> > on darwin. Regression tested on x86_64-apple-darwin12.
> > Okay for gcc trunk as well as gcc-4_7-branch/gcc-4_6-branch/gcc-4_5-branch?
>
> The 4.5 branch is closed, so definitely not alright there.
>
> I don't like the sched_yield macro being set there because it's
> detected correctly by configure anyway, but I'm not going to labour
> that point any more.
Since we are defining _GLIBCXX_USE_NANOSLEEP in os_defines.h and effectively
implementing half of the behavior of --enable-libstdcxx-time=yes, it seemed
odd to not complete the process and define _GLIBCXX_USE_SCHED_YIELD as well.
The usage is not as straight-forward as many other configure options
(especially in light of the absence of rt timer support on darwin).
>
> OK for trunk, it's not a regression so I'm not sure about the
> branches. If it doesn't cause problems on the trunk we can decide
> whether to apply it to the 4.7 branch later.
I guess the question is which branches have enough C++11 standard support to
make the change meaningful to the end user.