public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "jeremyhu at macports dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/54847] --enable-libstdcxx-time=yes doesn't find the function nanosleep() on darwin
Date: Mon, 08 Oct 2012 20:10:00 -0000	[thread overview]
Message-ID: <bug-54847-4-iI9Gf0dz28@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-54847-4@http.gcc.gnu.org/bugzilla/>


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.


  parent reply	other threads:[~2012-10-08 20:10 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-07 16:11 [Bug libstdc++/54847] New: --enable-libstdcxx-time=yes non-functional " howarth at nitro dot med.uc.edu
2012-10-07 17:31 ` [Bug libstdc++/54847] " paolo.carlini at oracle dot com
2012-10-07 17:40 ` jeremyhu at macports dot org
2012-10-07 18:02 ` paolo.carlini at oracle dot com
2012-10-07 18:35 ` jeremyhu at macports dot org
2012-10-07 18:51 ` howarth at nitro dot med.uc.edu
2012-10-07 18:54 ` howarth at nitro dot med.uc.edu
2012-10-07 19:04 ` jeremyhu at macports dot org
2012-10-07 19:22 ` howarth at nitro dot med.uc.edu
2012-10-07 19:38 ` jeremyhu at macports dot org
2012-10-07 19:43 ` howarth at nitro dot med.uc.edu
2012-10-07 20:11 ` howarth at nitro dot med.uc.edu
2012-10-07 22:17 ` howarth at nitro dot med.uc.edu
2012-10-07 22:29 ` howarth at nitro dot med.uc.edu
2012-10-07 22:51 ` jeremyhu at macports dot org
2012-10-07 23:03 ` paolo.carlini at oracle dot com
2012-10-07 23:07 ` jeremyhu at macports dot org
2012-10-07 23:14 ` roblu2184 at gmail dot com
2012-10-07 23:15 ` paolo.carlini at oracle dot com
2012-10-07 23:19 ` roblu2184 at gmail dot com
2012-10-07 23:26 ` jeremyhu at macports dot org
2012-10-07 23:33 ` paolo.carlini at oracle dot com
2012-10-08  3:48 ` jeremyhu at macports dot org
2012-10-08  9:26 ` paolo.carlini at oracle dot com
2012-10-08 10:06 ` redi at gcc dot gnu.org
2012-10-08 11:00 ` redi at gcc dot gnu.org
2012-10-08 11:17 ` redi at gcc dot gnu.org
2012-10-08 13:47 ` howarth at nitro dot med.uc.edu
2012-10-08 14:03 ` howarth at nitro dot med.uc.edu
2012-10-08 14:33 ` redi at gcc dot gnu.org
2012-10-08 14:47 ` redi at gcc dot gnu.org
2012-10-08 15:14 ` [Bug libstdc++/54847] --enable-libstdcxx-time=yes doesn't find the functional nanosleep() " howarth at nitro dot med.uc.edu
2012-10-08 15:31 ` howarth at nitro dot med.uc.edu
2012-10-08 15:55 ` redi at gcc dot gnu.org
2012-10-08 16:03 ` redi at gcc dot gnu.org
2012-10-08 16:31 ` howarth at nitro dot med.uc.edu
2012-10-08 16:45 ` howarth at nitro dot med.uc.edu
2012-10-08 16:48 ` [Bug libstdc++/54847] --enable-libstdcxx-time=yes doesn't find the function " redi at gcc dot gnu.org
2012-10-08 17:04 ` howarth at nitro dot med.uc.edu
2012-10-08 17:16 ` redi at gcc dot gnu.org
2012-10-08 18:33 ` jeremyhu at macports dot org
2012-10-08 19:50 ` redi at gcc dot gnu.org
2012-10-08 20:10 ` jeremyhu at macports dot org [this message]
2012-10-08 20:31 ` howarth at nitro dot med.uc.edu
2012-10-08 20:42 ` redi at gcc dot gnu.org
2012-10-08 22:27 ` howarth at nitro dot med.uc.edu
2012-10-09  0:46 ` howarth at nitro dot med.uc.edu
2012-10-10 23:20 ` redi at gcc dot gnu.org
2012-11-06 11:35 ` redi at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-54847-4-iI9Gf0dz28@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).