From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20055 invoked by alias); 8 Oct 2012 15:55:32 -0000 Received: (qmail 19918 invoked by uid 48); 8 Oct 2012 15:55:09 -0000 From: "redi at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/54847] --enable-libstdcxx-time=yes doesn't find the functional nanosleep() on darwin Date: Mon, 08 Oct 2012 15:55:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: redi at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-10/txt/msg00700.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847 --- Comment #33 from Jonathan Wakely 2012-10-08 15:55:07 UTC --- (In reply to comment #31) > (In reply to comment #30) > > Can we take a step back and determine what exactly this PR is about? Several > > of the comments make incorrect statements about the status quo, so I want to > > get the report clear. > > > > I don't understand comment 1. I meant comment 0 there. > The struct business is a red-herring and can be ignored. The test case without > struct > is compiled by g++ fine on darwin. Of course, that's what Paolo has been saying. > > > > Contrary to comment 2, the configure check for sched_yield does *not* check > > _POSIX_TIMERS, so sched_yield should be used on darwin when > > --enable-libstdcxx-time is used. Is _GLIBCXX_USE_SCHED_YIELD defined on darwin > > when the --enable-libstdcxx-time option is used? > > I read libstdc++-v3/acinclude.m4 to imply that the check for sched_yield is > only used > when configure is passed --enable-libstdcxx-time=rt, I didn't bother with that > case on > darwin because Jeremy said.... > > CLOCK_REALTIME isn't supported in darwin, so I wouldn't expect it to work > unless you had external implementation for the RT POSIX extension. > > ...off-list. You read it wrong. The sched_yield check is done for both --enable-libstdcxx-time=yes and --enable-libstdcxx-time=rt So is _GLIBCXX_USE_SCHED_YIELD defined on darwin? > > That option *doesn't* enable the use of clock_gettime on darwin, because the > > function isn't available. That's unavoidable. > > > > That option does enable checking for nanosleep, but the check fails on darwin > > because nanosleep is available but darwin doesn't identify itself as supporting > > the Timers option (presumably because the rest of the option isn't supported.) > > > > If that's correct, could we change the bug description to be more accurate? > > Done. Note that the man page for darwin nanosleep() can be found at... > > https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man2/nanosleep.2.html > > and claims... > > The nanosleep() function conforms to IEEE Std 1003.1b-1993 (``POSIX.1''). The problem isn't finding nanosleep, it's finding what version of POSIX or X/Open or SUS is supported, so we know what the correct feature test macros is for nanosleep. Is _XOPEN_REALTIME defined? If so, to what value? What about _XOPEN_VERSION and _POSIX_C_VERSION? Maybe we can find some other combination of feature test macros that indicate the POSIX Realtime extensions (POSIX.1b) are supported.