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 <math.h> #undef _GLIBCXX_INCLUDE_NEXT_C_HEADERS which appears to have the effect of forcing it to include /usr/include/math.h
It has the effect of skipping the first <math.h> that gets found, so that we don't end up in a loop. The purpose of that is to find the libc <math.h> rather than the libstdc++ one, so typically /usr/include/math.h, yes.
instead of the math.h from gnulib, which I expect is how gnulib worked with C++ before. This appears to be done now for all of the C++ C library header wrappers, e.g. cstdlib:
No, only for <math.h> and <stdlib.h>.
This is currently causing lots of trouble for octave by effectively disabling gnulib. Since octave uses the GNULIB_NAMESPACE of "gnulib", it is using things like "gnulib::floor", but since the gnulib math.h is no longer included there is no gnulib::floor declared.
<math.h> is a standard header, putting another header with that name in the include path is undefined behaviour. 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 to the gnulib headers needs to be specified with -isystem not -I so that it comes after the libstdc++ <math.h> not before it). If gnulib is not trying to be <math.h> but is just borrowing the name then it needs to change the name to avoid undefined behaviour.
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.
I'll look into it and see what gnulib is playing at. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
