[Octave-bug-tracker] [bug #61812] Math constants (e.g. M_PI) are not part of C/C++ standard

[Markus Mützel]

Follow-up Comment #27, bug #61812 (project octave):

Afaict, there is no gnulib module that would convert a compiler that doesn't
support GNU extensions to one that does. Their math module adds support for
some macros and functions for some platforms. But afaict, none of the XSI
macros.

However, using GNU extensions doesn't mean that we would be limited to gcc.
IIUC, many other compilers from different vendors support GNU extensions, too.
ISTR that clang aims to be source compatible to GCC. Another example are IBM's
compilers:
https://www.ibm.com/docs/en/xl-c-and-cpp-linux/16.1.1?topic=both-extensions-gnu-compatibility

IIUC, the math headers are standard library specific (not compiler specific).
That might be different for other GNU extensions.

I didn't fully understand it yet, but it might be that compiling with
`-std=gnu++11` (as opposed to `-std=c++11`) sets "_XOPEN_SOURCE 700". So, it's
no longer necessary to set it explicitly in the sources. (But I might be wrong
on this.)

Anyway, I'll probably remove the FIXME notes and push the patch from comment
#25 if no one opposes. With it the compiler features are checked in the
following order:
* If configuring with `--enable-std-pmr-polymorphic-allocator`, check if the
compiler supports C++17 with GNU extensions.
* If that fails, check if the compiler supports C++17 without GNU extensions.
* If that fails or configuring without
`--enable-std-pmr-polymorphic-allocator`, check if the compiler supports C++11
with GNU extensions.
* If that fails, check if the compiler supports C++11 without GNU extensions.
* If that fails, terminate configure with an error.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?61812>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/