[Top][All Lists]

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

More - Problems with mkoctfile using GCC 4.8.1

From: Terry Duell
Subject: More - Problems with mkoctfile using GCC 4.8.1
Date: Thu, 10 Oct 2013 13:22:10 +1100
User-agent: Opera Mail/12.16 (Linux)

On Tue, 08 Oct 2013 11:20:04 +1100, Terry Duell <address@hidden> wrote:

Hello All,
A result, see below.

On Mon, 07 Oct 2013 11:03:10 +1100, Terry Duell <address@hidden> wrote:

Hello All,
Running Octave 3.6.4 on Fedora 19 x86_64.

Trying to build a mex file, as follows;
"mkoctfile --mex apply_blur_kernel_mex.cpp" gives the following (partial) error message...

/usr/include/c++/4.8.1/cstdlib: In function ‘long long int std::abs(long long int)’: /usr/include/c++/4.8.1/cstdlib:174:20: error: declaration of C function ‘long long int std::abs(long long int)’ conflicts with
    abs(long long __x) { return __builtin_llabs (__x); }

A response posted to a similar error message (not related to Octave) was...

"That because header cstdlib is included in a 'extern "C"' block that gcc 4.8 doesn't support. Fix it by move the header file out of the 'extern "C"'

A look at /usr/include/octave-3.6.4/octave/mexproto.h, shows...

#if defined (__cplusplus)
#include <cstdlib>
extern "C" {
#include <stdlib.h>

I'm not sufficiently au fait with C and C++ to fully understand what is going on here. Does anyone know if this Is this the problem, and what is the recommended way I fix this?

I finally tracked down a bug report, from a little while ago, relating to this problem. The fix is to move the code ' #include "mexproto.h" ' in '/usr/include/octave-3.6.4/octave/mex.h' (the location in Octave 3.6.4 Fedora 19 x86_64) up about 8 lines to just prior to 'extern "C" {'.
When this done the mex file builds OK.

This isn't sorted after all.
Having successfully built mex files from cpp source using the above fix, I thought all was OK, but not so. Attempting to build mex from fred.c leads to errors. If the fix for cpp in mex.h is reversed, fred.c builds OK.

Can this be fixed so that both .c and .cpp source can be used?

Terry Duell

reply via email to

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