Major issues with g++ 6 and gnulib

[Orion Poplawski]

Fedora Rawhide is running with gcc 6 now. The fist issue I hit was with signbit:

https://savannah.gnu.org/bugs/?47073

I think I have a workaround for that, but next I got:

array/Range.cc: In function 'double tfloor(double, double)':
array/Range.cc:498:21: error: 'floor' is not a member of 'gnulib'
   double t1 = 1.0 + gnulib::floor (x);
                     ^~~~~~
I believe this is because as of 6.0.0, /usr/include/c++/6.0.0/cmath does:

#define _GLIBCXX_INCLUDE_NEXT_C_HEADERS
#include_next <math.h>
#undef _GLIBCXX_INCLUDE_NEXT_C_HEADERS

which appears to have the effect of forcing it to include /usr/include/math.h
instead of the math.h from gnulib, which I expect is how gnulib worked with
C++ before.  This is true for the other C++ headers as well, e.g. cstdlib:


// Need to ensure this finds the C library's <stdlib.h> not a libstdc++
// wrapper that might already be installed later in the include search path.
#define _GLIBCXX_INCLUDE_NEXT_C_HEADERS
#include_next <stdlib.h>
#undef _GLIBCXX_INCLUDE_NEXT_C_HEADERS


octave's lo-math.h does:

#if defined (__cplusplus)
#include <cmath>
// if #undef log2 is missing in cmath, undef it here
#if defined (log2)
#undef log2
#endif
#else
#include <math.h>
#endif

So it appears that gnulib's math.h will simply no longer be used.

I seem to be able to work around it at the moment by explicitly including
<math.h> before <cmath>, although I still haven't managed to get octave to
compile yet.  But I expect a better solution will need to be found for a
permanent fix.

-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA, Boulder/CoRA Office             FAX: 303-415-9702
3380 Mitchell Lane                       address@hidden
Boulder, CO 80301                   http://www.nwra.com