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

["redi at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot 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.