octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Major issues with g++ 6 and gnulib


From: John W. Eaton
Subject: Re: Major issues with g++ 6 and gnulib
Date: Sat, 20 Feb 2016 09:49:36 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0

On 02/19/2016 06:33 PM, Orion Poplawski wrote:
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

I think this comment means to say "installed earlier in the include search path", but anyway this change does seem to be aimed at blocking the method that gnulib uses to try to fix broken system 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.

This isn't really relevant to the problem. The reason for the above is just to allow us to include lo-math.h in either C++ or C code and get <cmath> in C++ and <math.h> in C. That's separate from the issue of gnulib expecting that <cmath> includes <math.h> in a way that will pick up the gnulib replacement for math.h.

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.

Right, I don't think we want to do

  #include <foo.h>
  #include <cfoo>

for every C++ header that replaces the corresponding C header.

I'll write a separate post with some additional info and thoughts
about what I see the issues to be and what we might do about them.

jwe





reply via email to

[Prev in Thread] Current Thread [Next in Thread]