[Bug libstdc++/54847] New: --enable-libstdcxx-time=yes non-functional on darwin

[Bug libstdc++/54847] New: --enable-libstdcxx-time=yes non-functional on darwin

[howarth at nitro dot med.uc.edu]

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

             Bug #: 54847
           Summary: --enable-libstdcxx-time=yes non-functional on darwin
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: howarth@nitro.med.uc.edu


The configure option --enable-libstdcxx-time=yes is non-functional on darwin
because the associated configure test requires posix-timer support which darwin
lacks. Darwin also lacks support for the tested clock_gettime call but does
have the sched_yield call available. Also it is odd that
--enable-libstdcxx-timer has been defaulted to no as this has left many darwin
users (including MacPorts) assuming that they are enabling it with that option.

[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin

[paolo.carlini at oracle dot com]

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

--- Comment #1 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-10-07 17:31:18 UTC ---
Isn't that odd, the documentation explains pretty well why.

[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin

[jeremyhu at macports dot org]

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

Jeremy Huddleston Sequoia <jeremyhu at macports dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jeremyhu at macports dot
                   |                            |org

--- Comment #2 from Jeremy Huddleston Sequoia <jeremyhu at macports dot org> 2012-10-07 17:39:52 UTC ---
I think Jack is confused regarding --enable-libstdcxx-timer.  From emailing me,
he seems to be under the impression that '--enable-libstdcxx-timer' is
equivalent to '--enable-libstdcxx-timer=no' ... if that is the case, then
something is certainly wrong since --enable-libstdcxx-timer should be
equivalent to '--enable-libstdcxx-timer=yes' ...

As for darwin ... we have sched_yield and nanosleep.  We don't have
clock_gettime.

Why are you testing for posix timer support in your checks for sched_yield and
nanosleep?

[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin

[paolo.carlini at oracle dot com]

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

--- Comment #3 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-10-07 18:02:30 UTC ---
As far as Darwin is concerned, simply, somebody knowing the target well has to
work out the details. So far, we only made sure that things work reasonably
well on GNU/Linux machines. Patches are welcome, as usual.

[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin

[jeremyhu at macports dot org]

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

--- Comment #4 from Jeremy Huddleston Sequoia <jeremyhu at macports dot org> 2012-10-07 18:35:24 UTC ---
(In reply to comment #3)
> As far as Darwin is concerned, simply, somebody knowing the target well has to
> work out the details. So far, we only made sure that things work reasonably
> well on GNU/Linux machines. Patches are welcome, as usual.

I know the target, and I'm willing to answer any questions you may have. 
Unfortunately as gcc is GPL3, I can't look at the code or offer services beyond
that.

Is there a particular reason why the check for nanosleep and sched_yield check
for _POSIX_TIMERS > 0?  That seems peculiar to me.

[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #5 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-10-07 18:50:09 UTC ---
As far as I can see the only usage of nanosleep() in libstdc++-v3 is in this
section of the include/std/thread header...

#ifdef _GLIBCXX_USE_NANOSLEEP
    /// sleep_for
    template<typename _Rep, typename _Period>
      inline void
      sleep_for(const chrono::duration<_Rep, _Period>& __rtime)
      {
        chrono::seconds __s =
          chrono::duration_cast<chrono::seconds>(__rtime);

        chrono::nanoseconds __ns =
          chrono::duration_cast<chrono::nanoseconds>(__rtime - __s);

        __gthread_time_t __ts =
          {
            static_cast<std::time_t>(__s.count()),
            static_cast<long>(__ns.count())
          };

        ::nanosleep(&__ts, 0);
      }

    /// sleep_until
    template<typename _Clock, typename _Duration>
      inline void
      sleep_until(const chrono::time_point<_Clock, _Duration>& __atime)
      { sleep_for(__atime - _Clock::now()); }
#endif

[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #6 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-10-07 18:53:53 UTC ---
Also, for Jeremy's benefit (since he can't look at the sources), the current
configure test is...

#include <unistd.h>
         #include <time.h>

int
main ()
{
#if _POSIX_TIMERS > 0 && defined(_POSIX_MONOTONIC_CLOCK)
          timespec tp;
         #endif
          clock_gettime(CLOCK_MONOTONIC, &tp);

  ;
  return 0;
}

[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin

[jeremyhu at macports dot org]

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

--- Comment #7 from Jeremy Huddleston Sequoia <jeremyhu at macports dot org> 2012-10-07 19:04:12 UTC ---
Yeah, Jack... your copying them and pasting them here just makes it easier for
me to accidentally read them.  Please don't do that.  The code is GPL3, and it
remains GPL3 even if you copy/paste it into this bug report.

[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #8 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-10-07 19:22:28 UTC ---
(In reply to comment #7)
> Yeah, Jack... your copying them and pasting them here just makes it easier for
> me to accidentally read them.  Please don't do that.  The code is GPL3, and it
> remains GPL3 even if you copy/paste it into this bug report.

Well you are bound to read code fragments that are GPLv3 in FSF gcc bugzilla so
I 
don't know what you expecting here. I would stop reading FSF gcc bugzilla if
you can't 
reasonably participate. Also, aren't headers considered different in context 
from source 
files? In any case, I grabbed the wrong test from configure...

#include <unistd.h>
         #include <time.h>

int
main ()
{
#if _POSIX_TIMERS > 0
          timespec tp;
         #endif
          nanosleep(&tp, 0);

  ;
  return 0;
}

[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin

[jeremyhu at macports dot org]

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

--- Comment #9 from Jeremy Huddleston Sequoia <jeremyhu at macports dot org> 2012-10-07 19:38:18 UTC ---
(In reply to comment #8)
> (In reply to comment #7)
> > Yeah, Jack... your copying them and pasting them here just makes it easier for
> > me to accidentally read them.  Please don't do that.  The code is GPL3, and it
> > remains GPL3 even if you copy/paste it into this bug report.
> 
> Well you are bound to read code fragments that are GPLv3 in FSF gcc bugzilla so
> I 
> don't know what you expecting here. I would stop reading FSF gcc bugzilla if
> you can't 
> reasonably participate.

I can certainly participate.  I just need to make sure that I don't read any
code snippets that are GPL3 licensed.

> Also, aren't headers considered different in context 
> from source 
> files?

It depends how they are licensed, but this is really a side conversation.

[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #10 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-10-07 19:43:25 UTC ---
(In reply to comment #9)
> 
> I can certainly participate.  I just need to make sure that I don't read any
> code snippets that are GPL3 licensed.
> 

Well it is absurd to read bugzilla and not expect to run across GPLv3 code
fragments. In any case, 
this minor change the configure test compiles and runs fine on
x86_64-apple-darwin11...

#include <unistd.h>
         #include <time.h>

int
main ()
{
#if _POSIX_TIMERS > 0
          timespec tp;
#else
          struct timespec tp;
#endif
          nanosleep(&tp, 0);

  ;
  return 0;
}

ISo the question is whether the header fragment needs any adjustment once the
configure passes the check for nanosleep() support. I'll test locally. 
    Paolo, are there any specific libstdc++-v3 test cases that I should look at
once libstc++-v3 is using nanosleep() to check for proper function?

[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #11 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-10-07 20:10:33 UTC ---
The manual change applied to configure works and the build ends up with...

#define _GLIBCXX_USE_NANOSLEEP 1

...in include/x86_64-apple-darwin12.2.0/bits/c++config.h. So we should be able
to fix this with...

Index: libstdc++-v3/acinclude.m4
===================================================================
--- libstdc++-v3/acinclude.m4    (revision 192186)
+++ libstdc++-v3/acinclude.m4    (working copy)
@@ -1251,6 +1251,8 @@ AC_DEFUN([GLIBCXX_ENABLE_LIBSTDCXX_TIME]
     ],
     [#if _POSIX_TIMERS > 0
       timespec tp;
+     #else
+      struct timespec tp;
      #endif
       nanosleep(&tp, 0);
     ], [ac_has_nanosleep=yes], [ac_has_nanosleep=no])

[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #12 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-10-07 22:17:15 UTC ---
Proposed patch in Comment 11 shows no regressions in the libstdc+-v3 test suite
on x86_64-apple-darwin12...


Native configuration is x86_64-apple-darwin12.2.0

        === libstdc++ tests ===


Running target unix/-m32

        === libstdc++ Summary for unix/-m32 ===

# of expected passes        8004
# of expected failures        43
# of unsupported tests        602

Running target unix/-m64

        === libstdc++ Summary for unix/-m64 ===

# of expected passes        8002
# of expected failures        43
# of unsupported tests        603

        === libstdc++ Summary ===

# of expected passes        16006
# of expected failures        86
# of unsupported tests        1205

Compiler version: gcc libstdc++ 
Platform: x86_64-apple-darwin12.2.0
configure flags: --prefix=/Users/howarth/dist --enable-languages=c,c++
--with-gmp=/sw --with-libiconv-prefix=/sw --with-isl=/sw --with-cloog=/sw
--with-mpc=/sw --with-system-zlib --enable-checking=yes
--x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--program-suffix=-fsf-4.8 --enable-libstdcxx-time=yes

[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #13 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-10-07 22:29:17 UTC ---
Patch posted at http://gcc.gnu.org/ml/gcc-patches/2012-10/msg00696.html.

[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin

[jeremyhu at macports dot org]

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

--- Comment #14 from Jeremy Huddleston Sequoia <jeremyhu at macports dot org> 2012-10-07 22:49:50 UTC ---
Your patch looks wrong to me.  You should just get rid of the '#if
_POSIX_TIMERS > 0' check and always use 'struct timespec' :

http://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_nanosleep.html

If there are some platforms which don't conform and need 'timespec' instead of
'struct timespec', then you can certainly work around those on a case by case
basis, but the _POSIX_TIMERS conditional has no reason to be there as far as I
can tell...

You should also do something similar for the clock_gettime and sched_yield
checks.

[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin

[paolo.carlini at oracle dot com]

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

--- Comment #15 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-10-07 23:03:09 UTC ---
Note that the autoconf test is built by the C++ compiler, thus there is no real
difference between timespec and struct timespec.

In general, remember that library patches should always go to the libstdc++
mailing list too (Jon is probably the best person to review changes in this
area and he doesn't track gcc-patches much, AFAIK)

[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin

[jeremyhu at macports dot org]

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

--- Comment #16 from Jeremy Huddleston Sequoia <jeremyhu at macports dot org> 2012-10-07 23:07:04 UTC ---
(In reply to comment #15)
> Note that the autoconf test is built by the C++ compiler, thus there is no real
> difference between timespec and struct timespec.

Except that one is POSIX and one is not.  Additionally, you shouldn't assume
that g++ is being used.  Hopefully, libstdc++ would be portable enough that one
wouldn't need to bootstrap g++ to build it.

[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin

[roblu2184 at gmail dot com]

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

--- Comment #17 from Rob Lu <roblu2184 at gmail dot com> 2012-10-07 23:13:59 UTC ---
Created attachment 28382
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28382
libstdc++-acinclude-timespec.patch

How about this as an option?

[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin

[paolo.carlini at oracle dot com]

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

--- Comment #18 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-10-07 23:14:55 UTC ---
To repeat what I meant: the autoconf test is built by the C++ compiler. Given
that, writing 'timespec' or writing 'struct timespec' is exactly the same. Just
wanted to clarify why, even from a formal point of view, the patch cannot be
right, I didn't really mean to analyze in any detail the existing autoconf test
(I didn't write this specific one, IIRC). Again send patches to libstdc++,
possibly CC Jon.

[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin

[roblu2184 at gmail dot com]

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

--- Comment #19 from Rob Lu <roblu2184 at gmail dot com> 2012-10-07 23:19:01 UTC ---
Created attachment 28383
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28383
libstdc++-configure-timespec

Here's a version that changes configure in case you don't want to rerun
autoconf.

[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin

[jeremyhu at macports dot org]

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

--- Comment #20 from Jeremy Huddleston Sequoia <jeremyhu at macports dot org> 2012-10-07 23:25:54 UTC ---
(In reply to comment #18)
> To repeat what I meant: the autoconf test is built by the C++ compiler. Given
> that, writing 'timespec' or writing 'struct timespec' is exactly the same.

C++ lets you just drop "struct"?  My C++ is very rusty, and I didn't realize
that.  That seems messy.  Thanks for the info.

> Just
> wanted to clarify why, even from a formal point of view, the patch cannot be
> right, I didn't really mean to analyze in any detail the existing autoconf test
> (I didn't write this specific one, IIRC). Again send patches to libstdc++,
> possibly CC Jon.

Yeah, that's why I'm suggesting just dropping the check for _POSIX_TIMERS > 0
... that check seems weird to me, and Jack's test seems to indicate that it's
not needed.

[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin

[paolo.carlini at oracle dot com]

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

--- Comment #21 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-10-07 23:33:41 UTC ---
If you do that, the test may be "correct" but becomes much weaker, you cannot
really assume anymore the POSIX behavior for such functions. You only know that
the functions are available. I have no idea, for example, whether on non
strictly POSIX systems (on strictly POSIX systems the test passes as-is) other
functions may work better, provide more accurate time, etc. Jon may know
better.

[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin

[jeremyhu at macports dot org]

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

--- Comment #22 from Jeremy Huddleston Sequoia <jeremyhu at macports dot org> 2012-10-08 03:48:00 UTC ---
Well we'll go with it for now.  I've bumped gcc48 in MacPorts using Rob's
version of the patch.  I'll update gcc47 and gcc46 after hearing back from Jon

[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin

[paolo.carlini at oracle dot com]

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

--- Comment #23 from Paolo Carlini <paolo.carlini at oracle dot com> 2012-10-08 09:25:53 UTC ---
Note that somebody has still to post an updated patch to the library mailing
list.

[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin

[redi at gcc dot gnu.org]

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

--- Comment #24 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-10-08 10:06:11 UTC ---
(In reply to comment #2)
> I think Jack is confused regarding --enable-libstdcxx-timer.  From emailing me,
> he seems to be under the impression that '--enable-libstdcxx-timer' is
> equivalent to '--enable-libstdcxx-timer=no' ... if that is the case, then
> something is certainly wrong since --enable-libstdcxx-timer should be
> equivalent to '--enable-libstdcxx-timer=yes' ...

It is equivalent.
(N.B. "time" not "timer")

> As for darwin ... we have sched_yield and nanosleep.  We don't have
> clock_gettime.
> 
> Why are you testing for posix timer support in your checks for sched_yield and
> nanosleep?

See http://gcc.gnu.org/ml/libstdc++/2012-05/msg00085.html for previous
suggestions for having more fine-grained checks than the current one for
--enable-libstdcxx-time 


(In reply to comment #13)
> Patch posted at http://gcc.gnu.org/ml/gcc-patches/2012-10/msg00696.html.

Jack, I've asked you before, please send libstdc++ patches to the libstdc++
list.  This patch is not acceptable, it doesn't "fix" anything, so consider it
rejected.

(In reply to comment #16)
> (In reply to comment #15)
> > Note that the autoconf test is built by the C++ compiler, thus there is no real
> > difference between timespec and struct timespec.
> 
> Except that one is POSIX and one is not.  Additionally, you shouldn't assume
> that g++ is being used.  Hopefully, libstdc++ would be portable enough that one
> wouldn't need to bootstrap g++ to build it.

But you do need a C++ compiler.

All patches to that code are rejected unless they get sent to the right list,
I'm not even going to review them otherwise, I'll just reject them.

Testing changes to those configure checks on a single platform proves nothing
about whether the change is correct.

[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin

[redi at gcc dot gnu.org]

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

--- Comment #25 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-10-08 10:59:46 UTC ---
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.

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.

[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin

[redi at gcc dot gnu.org]

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

--- Comment #26 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-10-08 11:17:26 UTC ---
(In reply to comment #24)
> > Except that one is POSIX and one is not.  Additionally, you shouldn't assume
> > that g++ is being used.  Hopefully, libstdc++ would be portable enough that one
> > wouldn't need to bootstrap g++ to build it.
> 
> But you do need a C++ compiler.

In fact, to *build* libstdc++ you definitely need G++.

An installed libstdc++ *might* be usable with other compilers such as ICC and
Clang that offer a sufficient level of GCC compatibility, but to install it in
the first place you need to use GCC.  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!

[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #27 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-10-08 13:47:32 UTC ---
The unistd.h header on darwin12 defines...

#define _POSIX_TIMERS                   (-1)            /* [TMR] */

>From the documentation on --enable-libstdcxx-time...

dnl Check for clock_gettime, nanosleep and sched_yield, used in the
dnl implementation of 20.11.7 [time.clock], and 30.3.2 [thread.thread.this]
dnl in the C++11 standard.
dnl
dnl --enable-libstdcxx-time
dnl --enable-libstdcxx-time=yes
dnl        checks for the availability of monotonic and realtime clocks,
dnl        nanosleep and sched_yield in libc and libposix4 and, if needed,
dnl        links in the latter.
dnl --enable-libstdcxx-time=rt
dnl        also searches (and, if needed, links) librt.  Note that this is
dnl        not always desirable because, in glibc, for example, in turn it
dnl        triggers the linking of libpthread too, which activates locking,
dnl        a large overhead for single-thread programs.
dnl --enable-libstdcxx-time=no
dnl --disable-libstdcxx-time
dnl        disables the checks completely

it seems that --enable-libstdcxx-time defaults to 'no' which would seem to
imply that it is effectively --disable-libstdcxx-time. The
--enable-libstdcxx-time=yes check is too strict for darwin because it doesn't
handle the case of _POSIX_TIMER defined to -1 for testing pre-POSIX 2008
nanosleep(). What would you consider to be an acceptable change to the test
at...

      AC_MSG_CHECKING([for nanosleep])
      AC_TRY_LINK(
        [#include <unistd.h>
         #include <time.h>
        ],
        [#if _POSIX_TIMERS > 0
          timespec tp;
         #endif
          nanosleep(&tp, 0);
        ], [ac_has_nanosleep=yes], [ac_has_nanosleep=no])

      AC_MSG_RESULT($ac_has_nanosleep)

in libstdc++-v3/acinclude.m4 to solve this limitation? Again I would note that
short-circuiting this test for  _POSIX_TIMERS > 0 introduces no regressions in
the libstdc++-v3 test suite so the darwin nanosleep() appears to be sufficient.
Or is the libstdc++-v3 testsuite currently incapable of properly testing this
feature?

[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #28 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-10-08 14:02:46 UTC ---
It seems like there is only two possible patches here using the existing
infrastructure in acinclude.m4 that would allow darwin's nanosleep() to be
found when passing --enable-libstdcxx-time=yes. Either...

Index: acinclude.m4
===================================================================
--- acinclude.m4    (revision 192206)
+++ acinclude.m4    (working copy)
@@ -1249,7 +1249,7 @@ AC_DEFUN([GLIBCXX_ENABLE_LIBSTDCXX_TIME]
     [#include <unistd.h>
      #include <time.h>
     ],
-    [#if _POSIX_TIMERS > 0
+    [#if _POSIX_TIMERS != 0
       timespec tp;
      #endif
       nanosleep(&tp, 0);

or 


Index: acinclude.m4
===================================================================
--- acinclude.m4    (revision 192206)
+++ acinclude.m4    (working copy)
@@ -1249,10 +1249,8 @@ AC_DEFUN([GLIBCXX_ENABLE_LIBSTDCXX_TIME]
     [#include <unistd.h>
      #include <time.h>
     ],
-    [#if _POSIX_TIMERS > 0
-      timespec tp;
-     #endif
-      nanosleep(&tp, 0);
+    [timespec tp;
+     nanosleep(&tp, 0);
     ], [ac_has_nanosleep=yes], [ac_has_nanosleep=no])

       AC_MSG_RESULT($ac_has_nanosleep)

Or are you going to demand that the use of pre-2008 POSIX nanosleep() be only
accepted on a target-specific basis?

[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin

[redi at gcc dot gnu.org]

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

--- Comment #29 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-10-08 14:32:42 UTC ---
(In reply to comment #28)
> It seems like there is only two possible patches here using the existing
> infrastructure in acinclude.m4 that would allow darwin's nanosleep() to be
> found when passing --enable-libstdcxx-time=yes. Either...
> 
> Index: acinclude.m4
> ===================================================================
> --- acinclude.m4    (revision 192206)
> +++ acinclude.m4    (working copy)
> @@ -1249,7 +1249,7 @@ AC_DEFUN([GLIBCXX_ENABLE_LIBSTDCXX_TIME]
>      [#include <unistd.h>
>       #include <time.h>
>      ],
> -    [#if _POSIX_TIMERS > 0
> +    [#if _POSIX_TIMERS != 0

This is just wrong.

See
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/unistd.h.html#tag_13_80_03_02
for the meaning of the values.

_POSIX_TIMERS=200112L would mean darwin provides a pre-2008 nanosleep, -1 means
the Timers option is not 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.

[Bug libstdc++/54847] --enable-libstdcxx-time=yes non-functional on darwin

[redi at gcc dot gnu.org]

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

--- Comment #30 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-10-08 14:47:20 UTC ---
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. 

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?

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?

[Bug libstdc++/54847] --enable-libstdcxx-time=yes doesn't find the functional nanosleep() on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #31 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-10-08 15:14:19 UTC ---
(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. 

The struct business is a red-herring and can be ignored. The test case without
struct
is compiled by g++ fine on darwin.

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

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

[Bug libstdc++/54847] --enable-libstdcxx-time=yes doesn't find the functional nanosleep() on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #32 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-10-08 15:31:30 UTC ---
Would something simple like...

Index: acinclude.m4
===================================================================
--- acinclude.m4    (revision 192212)
+++ acinclude.m4    (working copy)
@@ -1236,7 +1236,7 @@ AC_DEFUN([GLIBCXX_ENABLE_LIBSTDCXX_TIME]
     [#include <unistd.h>
      #include <time.h>
     ],
-    [#if _POSIX_TIMERS > 0
+    [#if (_POSIX_TIMERS > 0 || defined(__APPLE__))
       timespec tp;
      #endif
       clock_gettime(CLOCK_REALTIME, &tp);

be acceptable? We have the options of __APPLE_CC__, __APPLE__ or __MACH__ from
the preprocessor defines emitted by FSF gcc trunk on darwin.

[Bug libstdc++/54847] --enable-libstdcxx-time=yes doesn't find the functional nanosleep() on darwin

[redi at gcc dot gnu.org]

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

--- Comment #33 from Jonathan Wakely <redi at gcc dot gnu.org> 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.

[Bug libstdc++/54847] --enable-libstdcxx-time=yes doesn't find the functional nanosleep() on darwin

[redi at gcc dot gnu.org]

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

--- Comment #34 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-10-08 16:03:10 UTC ---
(In reply to comment #32)
> Would something simple like...
> 
> Index: acinclude.m4
> ===================================================================
> --- acinclude.m4    (revision 192212)
> +++ acinclude.m4    (working copy)
> @@ -1236,7 +1236,7 @@ AC_DEFUN([GLIBCXX_ENABLE_LIBSTDCXX_TIME]
>      [#include <unistd.h>
>       #include <time.h>
>      ],
> -    [#if _POSIX_TIMERS > 0
> +    [#if (_POSIX_TIMERS > 0 || defined(__APPLE__))
>        timespec tp;
>       #endif
>        clock_gettime(CLOCK_REALTIME, &tp);
> 
> be acceptable? We have the options of __APPLE_CC__, __APPLE__ or __MACH__ from
> the preprocessor defines emitted by FSF gcc trunk on darwin.

You might as well just #define _GLIBCXX_USE_NANOSLEEP in
config/os/bsd/darwin/os_defines.h

[Bug libstdc++/54847] --enable-libstdcxx-time=yes doesn't find the functional nanosleep() on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #35 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-10-08 16:31:11 UTC ---
(In reply to comment #33)

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

On darwin12, unistd.h shows...

#define _XOPEN_VERSION                  600             /* [XSI] */

#if __DARWIN_C_LEVEL >= 199506L /* This really should be XSI */
...
#define _XOPEN_REALTIME                 (-1)    /* no q'ed signals, mq_* */
#define _XOPEN_REALTIME_THREADS         (-1)    /* no posix_spawn, et. al. */
...
#endif /* XSI */

#if __DARWIN_C_LEVEL >= 199506L /* Really XSI */
...
#define _SC_XOPEN_REALTIME              111      /* Issue 6 */
#define _SC_XOPEN_REALTIME_THREADS      112  /* Issue 6 */
...
#define _SC_XOPEN_VERSION               116
....
#endif /* XSI */

/* _POSIX_VERSION and _POSIX2_VERSION from sys/unistd.h */

while sys/unistd.h doesn't have  _POSIX_C_VERSION but it does have 

#define _POSIX_VERSION          200112L
#define _POSIX2_VERSION         200112L

[Bug libstdc++/54847] --enable-libstdcxx-time=yes doesn't find the functional nanosleep() on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #36 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-10-08 16:44:53 UTC ---
(In reply to comment #33)

> So is _GLIBCXX_USE_SCHED_YIELD defined on darwin?

Yes, passing --enable-libstdcxx-time=yes and allowing nanosleep() to be found 
on darwin also results in...

./c++/4.8.0/x86_64-apple-darwin12.2.0/bits/c++config.h:#define
_GLIBCXX_USE_SCHED_YIELD 1
./c++/4.8.0/x86_64-apple-darwin12.2.0/i386/bits/c++config.h:#define
_GLIBCXX_USE_SCHED_YIELD 1

[Bug libstdc++/54847] --enable-libstdcxx-time=yes doesn't find the function nanosleep() on darwin

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-10-08
            Summary|--enable-libstdcxx-time=yes |--enable-libstdcxx-time=yes
                   |doesn't find the functional |doesn't find the function
                   |nanosleep() on darwin       |nanosleep() on darwin
     Ever Confirmed|0                           |1

--- Comment #37 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-10-08 16:47:46 UTC ---
(In reply to comment #36)
> (In reply to comment #33)
> 
> > So is _GLIBCXX_USE_SCHED_YIELD defined on darwin?
> 
> Yes, passing --enable-libstdcxx-time=yes and allowing nanosleep() to be found 
> on darwin also results in...
> 
> ./c++/4.8.0/x86_64-apple-darwin12.2.0/bits/c++config.h:#define
> _GLIBCXX_USE_SCHED_YIELD 1
> ./c++/4.8.0/x86_64-apple-darwin12.2.0/i386/bits/c++config.h:#define
> _GLIBCXX_USE_SCHED_YIELD 1

The check for sched_yield has nothing to do with nanosleep, that must have
always ben defined.

[Bug libstdc++/54847] --enable-libstdcxx-time=yes doesn't find the function nanosleep() on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #38 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-10-08 17:03:39 UTC ---
I assume the option of using...

Index: libstdc++-v3/config/os/bsd/darwin/os_defines.h
===================================================================
--- libstdc++-v3/config/os/bsd/darwin/os_defines.h    (revision 192213)
+++ libstdc++-v3/config/os/bsd/darwin/os_defines.h    (working copy)
@@ -42,4 +42,8 @@
 // Static initializer macro is buggy in darwin, see libstdc++/51906
 #define _GTHREAD_USE_RECURSIVE_MUTEX_INIT_FUNC

+// Use nanosleep and sched_yield in libc for C++11 standard.
+#define _GLIBCXX_USE_NANOSLEEP 1
+#define _GLIBCXX_USE_SCHED_YIELD 1
+
 #endif

...eliminates our ability to toggle this support off with
--disable-libstdcxx-time, right? This is my only concern with this approach
versus the patch in comment 32;

[Bug libstdc++/54847] --enable-libstdcxx-time=yes doesn't find the function nanosleep() on darwin

[redi at gcc dot gnu.org]

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

--- Comment #39 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-10-08 17:16:13 UTC ---
Yes, but why do you want to disable it?

Why does that patch define _GLIBCXX_USE_SCHED_YIELD?
That is correctly detected anyway by configure, without any changes, as I said
in comment 30 and again in comment 37

[Bug libstdc++/54847] --enable-libstdcxx-time=yes doesn't find the function nanosleep() on darwin

[jeremyhu at macports dot org]

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.

[Bug libstdc++/54847] --enable-libstdcxx-time=yes doesn't find the function nanosleep() on darwin

[redi at gcc dot gnu.org]

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

--- Comment #41 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-10-08 19:50:21 UTC ---
(In reply to comment #40)
> 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 existence of a function called nanosleep doesn't mean it's the right one,
or that it will be found at link time, or available at run-time.

Checking _POSIX_TIMERS > 0 means the functionality is actually usable, without
checking sysconf() at run-time as described by POSIX.1b-2001.

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

(That was a link to clock_nanosleep not nanosleep, which was a different
option, not Timers ;)
That comment wasn't aimed at you...

  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.

... but you do still seem to doubt that the struct is unnecessary in C++. 
Maybe you've noticed how you don't need to say:

   class std::string str = "a string";
   ^^^^^
to use C++ classes. It's the same for structs.

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

Again, there's a difference between *working* (i.e. being usable) on darwin and
being able to build libstdc++ with a different compiler.  There is no
requirement to be able to configure libstdc++ with anything other than G++, but
in any case I assure you that clang++ doesn't require the 'struct' keyword
either.


> It's not one system.  You are misreading the spec.

No I'm not, my words you quoted carefully made the distinction of saying -1
means the Timers option is not supported, not that nanosleep is not supported:

> > _POSIX_TIMERS=200112L would mean darwin provides a pre-2008 nanosleep, -1 means
> > the Timers option is not supported.

(I was admittedly less careful in comment 25, sorry)

I'd be happy to improve the test to support other systems, but the patches
posted to this PR so far have been unacceptable due to failing to understand
the existing checks, failing to meet libstdc++'s configury conventions, or
adding support for a single system rather than for any systems which provide
nanosleep without the rest of the Timers option.  In the absence of a decent
patch I suggest defining the HAVE_NANOSLEEP macro in os_defines.h and moving
on.


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

The existence of a preprocessor symbol doesn't tell you whether you need to
link to a particular library to use the function.

The check is AC_TRY_LINK which will ensure not only is the function declared
but the symbol is found, having added -lposix4 or -lrt to the link line if
earlier checks indicate they're needed.


> if you want to support all
> platforms, it's better to just check for nanosleep directly without the
> _POSIX_TIMERS check.

If _POSIX_TIMERS is defined to 0 the code might compile but not work at
run-time.  I didn't write those checks, but I'm not inclined to remove the
tests of the POSIX option macros just to fix this PR.


> > That is correctly detected anyway by configure, without any changes, as I said
> > in comment 30 and again in comment 37
> 
> Yes, it is.

Gread, thanks for confirming that.

[Bug libstdc++/54847] --enable-libstdcxx-time=yes doesn't find the function nanosleep() on darwin

[jeremyhu at macports dot org]

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

--- Comment #42 from Jeremy Huddleston Sequoia <jeremyhu at macports dot org> 2012-10-08 20:10:26 UTC ---
(In reply to comment #41)
> (In reply to comment #40)
> > 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 existence of a function called nanosleep doesn't mean it's the right one,
> or that it will be found at link time, or available at run-time.
> 
> Checking _POSIX_TIMERS > 0 means the functionality is actually usable, without
> checking sysconf() at run-time as described by POSIX.1b-2001.
> 

Right, but as we see here, the converse is not true.  ie:

This is true:
(_POSIX_TIMERS > 0) => (nanosleep is the one you want)

This is not true:
(nanosleep is the one you want) => (_POSIX_TIMERS > 0)

You want to find an test such that:

(your test) <=> (nanosleep is the one you want)

> (That was a link to clock_nanosleep not nanosleep, which was a different
> option, not Timers ;)

Aww sorry.  I copy-linked the wrong one, but meh.

> ... but you do still seem to doubt that the struct is unnecessary in C++. 

No.  I don't doubt that.  I admitted in comment #20 that C++ is not a strength
of mine, so thanks for letting me know about this detail.

> Maybe you've noticed how you don't need to say:
> 
>    class std::string str = "a string";
>    ^^^^^
> to use C++ classes. It's the same for structs.

Yeah, I knew about class, but I didn't know about that for structs.  I thought
it wasn't possible to drop 'struct' in C++ as it's not possible to drop it in C
(although most users will typedef).  Thanks for teaching me something new.

> Again, there's a difference between *working* (i.e. being usable) on darwin and
> being able to build libstdc++ with a different compiler.  There is no
> requirement to be able to configure libstdc++ with anything other than G++, but
> in any case I assure you that clang++ doesn't require the 'struct' keyword
> either.

I don't doubt it.  I was just trying to make the usage strictly match the POSIX
spec.

> > It's not one system.  You are misreading the spec.
> 
> No I'm not, my words you quoted carefully made the distinction of saying -1
> means the Timers option is not supported, not that nanosleep is not supported:

Ok.

> I'd be happy to improve the test to support other systems, but the patches
> posted to this PR so far have been unacceptable due to failing to understand
> the existing checks, failing to meet libstdc++'s configury conventions, or
> adding support for a single system rather than for any systems which provide
> nanosleep without the rest of the Timers option.  In the absence of a decent
> patch I suggest defining the HAVE_NANOSLEEP macro in os_defines.h and moving
> on.

> > 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...
> 
> The existence of a preprocessor symbol doesn't tell you whether you need to
> link to a particular library to use the function.

Ah, I forgot you were checking for library linkage as well.  That makes sense.

> The check is AC_TRY_LINK which will ensure not only is the function declared
> but the symbol is found, having added -lposix4 or -lrt to the link line if
> earlier checks indicate they're needed.

That makes sense.

> > if you want to support all
> > platforms, it's better to just check for nanosleep directly without the
> > _POSIX_TIMERS check.
> 
> If _POSIX_TIMERS is defined to 0 the code might compile but not work at
> run-time.  I didn't write those checks, but I'm not inclined to remove the
> tests of the POSIX option macros just to fix this PR.

Ok, what about just using _POSIX_TIMERS > 0 || defined(__APPLE__)?  That may
miss some other OSs in the same boat, but they can always add similar checks.

[Bug libstdc++/54847] --enable-libstdcxx-time=yes doesn't find the function nanosleep() on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #43 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-10-08 20:31:01 UTC ---
Both OpenBSD and FreeBSD seem to have nanosleep calls documented as...

The nanosleep() function conforms to IEEE Std 1003.1b-1993 (``POSIX'')

like Apple's. On the other hand, using a patch like...

Index: libstdc++-v3/config/os/bsd/darwin/os_defines.h
===================================================================
--- libstdc++-v3/config/os/bsd/darwin/os_defines.h    (revision 192222)
+++ libstdc++-v3/config/os/bsd/darwin/os_defines.h    (working copy)
@@ -42,4 +42,9 @@
 // Static initializer macro is buggy in darwin, see libstdc++/51906
 #define _GTHREAD_USE_RECURSIVE_MUTEX_INIT_FUNC

+// Use nanosleep and sched_yield in libc for time.clock and 
+// thread.thread.this in C++11 standard.
+#define _GLIBCXX_USE_NANOSLEEP 1
+#define _GLIBCXX_USE_SCHED_YIELD 1
+
 #endif

will effectively default darwin to --enable-libstdcxx-time=yes and eliminates a
configure option.

[Bug libstdc++/54847] --enable-libstdcxx-time=yes doesn't find the function nanosleep() on darwin

[redi at gcc dot gnu.org]

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

--- Comment #44 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-10-08 20:42:22 UTC ---
(In reply to comment #42)
> You want to find an test such that:
> 
> (your test) <=> (nanosleep is the one you want)

That's why I was asking about other feature test macros that would allow us to
detect systems supporting the POSIX.1b-1993 Realtime Extensions, but not the
later Timers option, or the POSIX-2008 Base.


> Ok, what about just using _POSIX_TIMERS > 0 || defined(__APPLE__)?  That may
> miss some other OSs in the same boat, but they can always add similar checks.

Because we generally try to avoid littering acinclude.m4 with such checks.  The
other OSs can add defines to their own os_defines.h files if needed.


(In reply to comment #43)
> will effectively default darwin to --enable-libstdcxx-time=yes and eliminates a
> configure option.

That's a *good* thing. If the platform unconditionally supports the feature and
doesn't need a configure check why would you want to prevent using it?  All
that achieves is an incomplete libstdc++ with missing functionality.

[Bug libstdc++/54847] --enable-libstdcxx-time=yes doesn't find the function nanosleep() on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #45 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-10-08 22:27:08 UTC ---
I can confirm the existence of sched_yield() back to Libc-166 in 1997 on
darwin.

http://opensource.apple.com/source/Libc/Libc-166/pthreads.subproj/sched.h

The nanosleep() call appears at least by Libc-262.2.12 in 2003 on darwin...

http://opensource.apple.com/source/Libc/Libc-262.2.12/include/time.h

and probably goes back further but the archived Libc don't show the time.h
header before then.

[Bug libstdc++/54847] --enable-libstdcxx-time=yes doesn't find the function nanosleep() on darwin

[howarth at nitro dot med.uc.edu]

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

--- Comment #46 from Jack Howarth <howarth at nitro dot med.uc.edu> 2012-10-09 00:46:08 UTC ---
Revised patch posted to libstdc++ mailing list...

http://gcc.gnu.org/ml/libstdc++/2012-10/msg00047.html

[Bug libstdc++/54847] --enable-libstdcxx-time=yes doesn't find the function nanosleep() on darwin

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.8.0

--- Comment #47 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-10-10 23:19:56 UTC ---
should be fixed on trunk, by
http://gcc.gnu.org/ml/gcc-cvs/2012-10/msg00457.html

[Bug libstdc++/54847] --enable-libstdcxx-time=yes doesn't find the function nanosleep() on darwin

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #48 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-11-06 11:35:22 UTC ---
Fixed for 4.8