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 <math.h> before <cmath>,
That might actually be a reasonable fix. There is no guarantee whatsoever that <cmath> includes <math.h>, so it is not portable and not guaranteed to work when Octave assumes that including <cmath> will indirectly include gnulib's <math.h>. If Octave wants to include gnulib's <math.h> then it should be including it itself, not relying on some other header doing so indirectly. Furthermore, when GCC's <cmath> wants to include <math.h> it *really* does want libc's <math.h>, which is what GCC was configured against, and what it expects to find again when you compile. If some other <math.h> turns up it could break all sorts of things. Gnulib does seem to be going to some lengths to co-operate with the real <math.h> (using #include_next itself, and putting everything in a namespace when requested to) but it's entirely right that <cmath> gets to decide what it wants to include, Octave should not be interfering with the implementation's headers. So for Octave to include gnulib's <math.h> either it should have a different name, such as <gl_math.h>, or it should include it as <libgnu/math.h>, or just ensure it is included directly, and not as a side effect of including <cmath>. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
