public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
From: Yaakov Selkowitz <yselkowi@redhat.com>
To: Newlib <newlib@sourceware.org>
Subject: Re: Feature Conditional for M_PI
Date: Mon, 31 Aug 2020 22:04:20 -0400	[thread overview]
Message-ID: <71636f44a4b664631d88abf94108c0ee32f161bd.camel@redhat.com> (raw)
In-Reply-To: <CAF9ehCXUrJ8c5YhAciuaNdeL5eqziDQA54Xw0LCt-X8h07nsgQ@mail.gmail.com>

On Mon, 2020-08-31 at 16:19 -0500, Joel Sherrill via Newlib wrote:
> On Mon, Aug 31, 2020 at 3:05 PM Corinna Vinschen via Newlib <
> newlib@sourceware.org> wrote:
> 
> > On Aug 31 10:50, Joel Sherrill wrote:
> > > On Mon, Aug 31, 2020 at 10:30 AM Corinna Vinschen via Newlib <
> > > newlib@sourceware.org> wrote:
> > > 
> > > > On Aug 31 17:27, Corinna Vinschen via Newlib wrote:
> > > > > On Aug 31 10:10, Joel Sherrill wrote:
> > > > > > Hi
> > > > > > 
> > > > > > I was porting some code from Linux to Cygwin and came across this.
> > > > M_PI in
> > > > > > math.h is defined by POSIX as part of XSI. It does not appear to be
> > > > part of
> > > > > > C99 or C++03.  I have this cut down to show the problem:
> > > > > > 
> > > > > > ==========================
> > > > > > #include <math.h>
> > > > > > 
> > > > > > double pi = M_PI;
> > > > > > ==========================
> > > > > > 
> > > > > > And this script to try various feature defines and compilers:
> > > > > > 
> > > > > > ===========================
> > > > > > GCC=${GCC:-g++}
> > > > > > 
> > > > > > ${GCC} -c m.c
> > > > > > ${GCC} -D_XOPEN_SOURCE=700 -c m.c
> > > > > > ${GCC} -D_POSIX_C_SOURCE=200809L -c m.c
> > > > > > ${GCC} -D_XOPEN_SOURCE=700 -c -D_POSIX_C_SOURCE=200809L -c m.c
> > > > > > ===========================
> > > > > > 
> > > > > > All of those compiler invocations work on Linux but the third one
> > does
> > > > not
> > > > > > work on Cygwin or RTEMS which use newlib.
> > > > > > 
> > > > > > Is the proper thing to do to add  -D_XOPEN_SOURCE=700 when
> > compiling
> > > > this
> > > > > > program?
> > > > > > 
> > > > > > Just curious if Linux is defining _XOPEN_SOURCE by default and
> > newlib
> > > > > > doesn't.
> > 
> > Actually, Yaakov pointed out on IRC that this is a C++ problem on Linux.
> > You're running the above test with g++.  If you perform the third test
> > with gcc on Linux:
> > 
> >   gcc -D_POSIX_C_SOURCE=200809L -c m.c
> > 
> > you'll get the same error as on newlib and FreeBSD:
> > 
> > m.c: In function ‘main’:
> > m.c:8:15: error: ‘M_PI’ undeclared (first use in this function)
> >     8 |   double pi = M_PI;
> >           |               ^~~~
> >           m.c:8:15: note: each undeclared identifier is reported only once
> > for each function it appears in
> > 
> > The problem in glibc and/or g++ is that this does *not* occur when
> > building with g++.
> > 
> 
> Thanks. I was building with g++ because the code this came up in was C++.
> In the application, I just defined the proper thing to make it visible.
> 
> Was this the right thing to do? Or is there something else wrong? Honestly,
> the odd C library things that happen from C++ is often hard to explain.

Yes, that is the correct solution.

Unfortunately, the work to automatically make visible the symbols
required by various C++ standards hasn't been done in glibc, therefore
on Linux targets, G++ defines _GNU_SOURCE which enables everything.  To
that end, newlib/cygwin are actually more correct than glibc, but this
is the price for being correct.

Fixing this in glibc and g++ has been on my to-do wish list since the
newlib/cygwin FTMs were finished, but I just haven't had the time.

-- 
Yaakov Selkowitz
Senior Software Engineer - Platform Enablement
Red Hat,
Inc.


      reply	other threads:[~2020-09-01  2:04 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-31 15:10 Joel Sherrill
2020-08-31 15:27 ` Corinna Vinschen
2020-08-31 15:29   ` Corinna Vinschen
2020-08-31 15:50     ` Joel Sherrill
2020-08-31 20:04       ` Corinna Vinschen
2020-08-31 21:19         ` Joel Sherrill
2020-09-01  2:04           ` Yaakov Selkowitz [this message]

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=71636f44a4b664631d88abf94108c0ee32f161bd.camel@redhat.com \
    --to=yselkowi@redhat.com \
    --cc=newlib@sourceware.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).