On 20/02/16 08:36 -0700, Orion Poplawski wrote:
On 02/19/2016 08:24 PM, Jonathan Wakely wrote:
On 20/02/16 02:07 +, Jonathan Wakely wrote:
The next problem is that gnulib defines:
inline int signbit (float f) { return _gl_cxx_signbitf (f); } inline
int signbit (double d) { return _gl_cxx_s
On 02/19/2016 08:24 PM, Jonathan Wakely wrote:
On 20/02/16 02:07 +, Jonathan Wakely wrote:
The next problem is that gnulib defines:
inline int signbit (float f) { return _gl_cxx_signbitf (f); } inline
int signbit (double d) { return _gl_cxx_signbitd (d); } inline int
signbit (long double l)
On 20/02/16 02:07 +, Jonathan Wakely wrote:
The next problem is that gnulib defines:
inline int signbit (float f) { return _gl_cxx_signbitf (f); } inline
int signbit (double d) { return _gl_cxx_signbitd (d); } inline int
signbit (long double l) { return _gl_cxx_signbitl (l); }
GCC 6 provide
On 02/19/2016 07:07 PM, Jonathan Wakely wrote:
The next problem is that gnulib defines:
inline int signbit (float f) { return _gl_cxx_signbitf (f); } inline
int signbit (double d) { return _gl_cxx_signbitd (d); } inline int
signbit (long double l) { return _gl_cxx_signbitl (l); }
GCC 6 provides
The next problem is that gnulib defines:
inline int signbit (float f) { return _gl_cxx_signbitf (f); } inline
int signbit (double d) { return _gl_cxx_signbitd (d); } inline int
signbit (long double l) { return _gl_cxx_signbitl (l); }
GCC 6 provides a standard-conforming which defines the same
s
On 19/02/16 16:33 -0700, Orion Poplawski wrote:
I seem to be able to work around it at the moment by explicitly including
before ,
That might actually be a reasonable fix.
There is no guarantee whatsoever that includes , so it
is not portable and not guaranteed to work when Octave assumes th
On 19/02/16 23:45 +, Jonathan Wakely wrote:
If gnulib wants to play at being the standard library it needs to do
so correctly, to be compatible with whatever standard library is it
pretending to be, as documented at
https://gcc.gnu.org/gcc-6/porting_to.html (which would probably mean
the path
On 19/02/16 16:33 -0700, Orion Poplawski wrote:
It appears that as of 6.0.0, /usr/include/c++/6.0.0/cmath does:
#define _GLIBCXX_INCLUDE_NEXT_C_HEADERS
#include_next
#undef _GLIBCXX_INCLUDE_NEXT_C_HEADERS
which appears to have the effect of forcing it to include /usr/include/math.h
It has th
