[Bug libstdc++/54847] --enable-libstdcxx-time=yes doesn't find the function nanosleep() on darwin
jeremyhu at macports dot org
gcc-bugzilla@gcc.gnu.org
Mon Oct 8 20:10:00 GMT 2012
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.
More information about the Gcc-bugs
mailing list