bugGNU Octave - Bugs: bug #38746, Including mex.h does not work with...

 
 

bug #38746: Including mex.h does not work with G++ 4.8

Submitter:  Sébastien Villemot <svillemot>
Submitted:  Mon 15 Apr 2013 03:45:37 PM UTC
 
Category:  Libraries Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Other
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * 3.6.4 Operating System:  * GNU/Linux
* Mandatory Fields

Add a New Comment (Rich Markup)
   

Comment Type & Canned Response:
       

 

( Jump to the original submission )

Thu 30 May 2013 06:15:06 PM UTC, comment #7: 
John W. Eaton <jwe>
Project Administrator
Sun 26 May 2013 07:47:39 PM UTC, comment #6: 

Here's a patch implementing the original suggestion by Sébastien, which is to include mexproto.h outside the extern "C" block in mex.h. That way cstdlib will continue to be included in C++ code.

(file #28181)

Clemens Buchacher <drizzd>
Wed 22 May 2013 09:54:55 AM UTC, comment #5: 

Some additional notes for replicating the problem on Debian sid (unstable).

You need to install package g++-4.8. Then the example given by Clemens has to be compiled with:

CXX=g++-4.8 mkoctfile --mex mex_empty.cpp

I get a compilation failure with Octave 3.6.4 (did not try with devel branch). If I do not set CXX=g++-4.8, then it uses GCC 4.7 (current default on Debian sid), and the program compiles.

Sébastien Villemot <svillemot>
Tue 21 May 2013 09:36:40 PM UTC, comment #4: 

Below is a simple testcase with revision 16692:c19cc8c158b3 (this Saturday).

$ cat <<EOF >mex_empty.cpp
#include "mex.h"
void mexFunction(int nlhs, mxArray* plhs[], int nrhs, const mxArray* prhs[]) {}
EOF
$  ~/.local/octave-dev/bin/mkoctfile --mex mex_empty.cpp
In file included from /home/drizzd/.local/octave-dev/include/octave-3.7.5/octave/mexproto.h:52:0,
                 from /home/drizzd/.local/octave-dev/include/octave-3.7.5/octave/mex.h:77,
                 from mex_empty.cpp:1:
/usr/include/c++/4.8.0/cstdlib: In function ‘long long int std::abs(long long int)’:
/usr/include/c++/4.8.0/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); }
                    ^
/usr/include/c++/4.8.0/cstdlib:166:3: error: previous declaration ‘long int std::abs(long int)’ here
   abs(long __i) { return __builtin_labs(__i); }
   ^
/usr/include/c++/4.8.0/cstdlib: In function ‘__int128 std::abs(__int128)’:
/usr/include/c++/4.8.0/cstdlib:179:19: error: declaration of C function ‘__int128 std::abs(__int128)’ conflicts with
   abs(__int128 __x) { return __x >= 0 ? __x : -__x; }
                   ^
/usr/include/c++/4.8.0/cstdlib:174:3: error: previous declaration ‘long long int std::abs(long long int)’ here
   abs(long long __x) { return __builtin_llabs (__x); }
   ^
/usr/include/c++/4.8.0/cstdlib:179:19: error: declaration of C function ‘__int128 std::abs(__int128)’ conflicts with
   abs(__int128 __x) { return __x >= 0 ? __x : -__x; }
                   ^
/usr/include/c++/4.8.0/cstdlib:166:3: error: previous declaration ‘long int std::abs(long int)’ here
   abs(long __i) { return __builtin_labs(__i); }
   ^

I get the same output with this:

$ g++ -save-temps -c -I/home/drizzd/.local/octave-dev/include/octave-3.7.5/octave mex_empty.cpp

I am attaching mex_empty.ii and mex_empty.s from that command. I am also attaching /usr/include/c++/4.8.0/cstdlib.

GCC Sources:
_snapshot=4.8-20130502
source=(ftp://gcc.gnu.org/pub/gcc/snapshots/${_snapshot}/gcc-${_snapshot}.tar.bz2)

On my system GCC is built without patches, with the following flags:

CPPFLAGS="-D_FORTIFY_SOURCE=2"
CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4"
CXXFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro"
  # using -pipe causes spurious test-suite failures
  # http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48565
  CFLAGS=${CFLAGS/-pipe/}
  CXXFLAGS=${CXXFLAGS/-pipe/}

  ${srcdir}/${_basedir}/configure --prefix=/usr \
      --libdir=/usr/lib --libexecdir=/usr/lib \
      --mandir=/usr/share/man --infodir=/usr/share/info \
      --with-bugurl=https://bugs.archlinux.org/ \
      --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ \
      --enable-shared --enable-threads=posix \
      --with-system-zlib --enable-__cxa_atexit \
      --disable-libunwind-exceptions --enable-clocale=gnu \
      --disable-libstdcxx-pch \
      --enable-gnu-unique-object --enable-linker-build-id \
      --enable-cloog-backend=isl --disable-cloog-version-check \
      --enable-lto --enable-gold --enable-ld=default \
      --enable-plugin --with-plugin-ld=ld.gold \
      --with-linker-hash-style=gnu --disable-install-libiberty \
      --disable-multilib --disable-libssp --disable-werror \
      --enable-checking=release
  make

(file #28132, file #28133, file #28134)

Clemens Buchacher <drizzd>
Mon 20 May 2013 09:37:13 PM UTC, comment #3: 

Also, can someone please post a precise recipe for reproducing the problem?  I'm not seeing any problem compling a mex file with GCC 4.8 on my system using the current development sources.  I'd like to understand exactly what the problem is before applying a patch.

John W. Eaton <jwe>
Project Administrator
Mon 20 May 2013 09:33:54 PM UTC, comment #2: 

I would prefer a fix that ensures that we include cstdlib in C++ code because cstdlib is supposed to avoid macro definitions that stdlib.h may provide.

John W. Eaton <jwe>
Project Administrator
Sat 04 May 2013 04:32:01 PM UTC, comment #1: 

The patch below fixes the issue for me. Instead of disallowing mexproto.h to be included from extern "C" context, I think it is more appropriate instead not to include C++ header files such as cstdlib in a header file which declares only C functions. I am not sure what the motivation was for doing so, but for the record, there are two more files with similar constructs of the form #ifdef __cpluslus #include <cheader> extern "C" { #else <header.h> #include #endif:

 libinterp/interp-core/cutils.h
 liboctave/cruft/misc/quit.h

I did not touch those to keep the change minimal.

---
diff -r a1f613e5066d libinterp/interp-core/mexproto.h
--- a/libinterp/interp-core/mexproto.h  Sat May 04 09:37:28 2013 +0200
+++ b/libinterp/interp-core/mexproto.h  Sat May 04 16:37:00 2013 +0200
@@ -49,11 +49,10 @@
 #define MEXPROTO_H

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

 /* The definition of OCTINTERP_API is normally provided by Octave's
    config.h file.  This is provided for the case of mex.h included by

Clemens Buchacher <drizzd>
Mon 15 Apr 2013 03:45:37 PM UTC, original submission:  

This is Debian bug #705485 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705485)

When including mex.h from a C++ source file, and compiling with G++ 4.8, the compilation crashes.

The root of the problem is that mex.h includes mexproto.h within an extern "C" block. In turn, mexproto.h includes cstdlib.

Apparently, including cstdlib within an extern "C" block was working with G++ 4.7, but this is no longer the case.

The fix is to include mexproto.h outside of the extern "C" block.

Sébastien Villemot <svillemot>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #28181:  gcc-v2.patch added by drizzd (829B - text/x-patch)
file #28134:  mex_empty.ii added by drizzd (37KiB - application/octet-stream)
file #28132:  mex_empty.s added by drizzd (23B - application/octet-stream)
file #28133:  cstdlib added by drizzd (6KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by jordigh (Updated the item)
  • -email is unavailable- added by drizzd (Posted a comment)
  • -email is unavailable- added by svillemot (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only project members can vote.

     

     

     

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-05-30 jwe StatusPatch Submitted Fixed
        Open/ClosedOpen Closed
    2013-05-26 drizzd Attached File- Added gcc-v2.patch, #28181
    2013-05-21 drizzd Attached File- Added mex_empty.s, #28132
        Attached File- Added cstdlib, #28133
        Attached File- Added mex_empty.ii, #28134
    2013-05-20 jordigh StatusNone Patch Submitted

    Back to the top


    Powered by Savane 3.9