http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54847
--- Comment #40 from Jeremy Huddleston Sequoia <jeremyhu at macports dot org> 2012-10-08 18:33:37 UTC --- (In reply to comment #25) > N.B. prior to POSIX 2008 nanosleep was part of the Timers option, if OS X > supports that it should define _POSIX_TIMERS to 0, -1 or 200112L to indicate > it's supported. POSIX 2008 moves the Timers functionality to the Base spec, > and requires that _POSIX_TIMERS is defined to 200809L. In eiher case, a POSIX > system supporting nanosleep should define _POSIX_TIMERS. It is defined to -1 because OS X does not support all that _POSIX_TIMERS entails. I still don't see why the _POSIX_TIMERS > 0 check exists at all. On systems that don't have it, the tests will simply fail because timespec or nanosleep are undefined. > The configure checks are based on well-documented, publicly-available > standards, please try to understand them instead of proposing patches based on > the misunderstanding that adding "struct" makes any difference to anything. I very much understand the standards, and I've provided a link to them. The standard itself does not require _POSIX_TIMERS to be defined for nanosleep to be supported, and it specifically states 'struct timespec' in the function prototype. (In reply to comment #26) > If Apple or anyone else wants it to work > otherwise they need to do the work, as GCC maintainers have no reason to do > support building parts of GCC without GCC! Apple is fully committed to libc++. If anyone wants libstdc++ to work on Darwin, it is clear that it will need to be a community effort. (In reply to comment #29) > _POSIX_TIMERS=200112L would mean darwin provides a pre-2008 nanosleep, -1 > means > the Timers option is not supported. Yes, it is not *fully* supported. > > Or are you going to demand that the use of pre-2008 POSIX nanosleep() be > > only > > accepted on a target-specific basis? > > There are plenty of systems with a 2001 nanosleep that define _POSIX_TIMERS to > 20112L, but darwin seems to support nanosleep without the rest of the Timers > option. I don't want to remove the correct check for _POSIX_TIMERS just for > one system's peculiarities. It's not one system. You are misreading the spec. _POSIX_TIMERS > 0 implies that all the functionality is available. That is the only thing you can deduce from that check. It is perfectly valid to have a conforming nanosleep with _POSIX_TIMERS = -1. Why are you even othering to put that code inside of a _POSIX_TIMERS > 0 check. If _POSIX_TIMERS > 0, you're guaranteed (by the standard) to have that functionality, so there's no point in checking... if you want to support all platforms, it's better to just check for nanosleep directly without the _POSIX_TIMERS check. (In reply to comment #39) > Yes, but why do you want to disable it? > > Why does that patch define _GLIBCXX_USE_SCHED_YIELD? I think his patch has no effect on _GLIBCXX_USE_SCHED_YIELD ... I think he wasn't seeing _GLIBCXX_USE_SCHED_YIELD before because of a mistype he was having with the configure option. With Rob's patch, I see both _GLIBCXX_USE_SCHED_YIELD and _GLIBCXX_USE_NANOSLEEP defined to 1. > That is correctly detected anyway by configure, without any changes, as I said > in comment 30 and again in comment 37 Yes, it is.
