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@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
