Node-gyp: error: exception handling disabled, use -fexceptions to enable

Created on 11 Feb 2012  Â·  15Comments  Â·  Source: nodejs/node-gyp

I'm trying to update zeromq.node to use gyp as part of the process of getting it running on Windows (JustinTulloss/zeromq.node#81). I'm currently blocked by gyp's -fno-exceptions default (I think), but will probably run into linking issues soon enough.

Here's binding.gyp:

{
  'targets': [
    {
      'target_name': 'binding',
      'sources': [ 'binding.cc' ],
      'cflags': ['-fexceptions'],
      'cflags_cc': ['-fexceptions']
    }
  ]
}

Here's a transcript:

seth@lotus:~/src/JustinTulloss/zeromq.node [âš¡ gyp] $ node-gyp configure --target=0.7
info it worked if it ends with ok 
spawn python [ '/Users/seth/.node-gyp/0.7/tools/gyp_addon',
  '-f',
  'make',
  '--suffix',
  '.gyp',
  '-I',
  '/Users/seth/.node-gyp/0.7/tools/patch2722.gypi',
  '-Dtarget_arch=x64' ]
info done ok 
seth@lotus:~/src/JustinTulloss/zeromq.node [âš¡ gyp] $ node-gyp build
info it worked if it ends with ok 
spawn make [ 'BUILDTYPE=Release', '-f', 'Makefile.gyp' ]
  CXX(target) out/Release/obj.target/binding/binding.o
binding.cc: In constructor ‘zmq::Context::Context(int)’:
binding.cc:185: error: exception handling disabled, use -fexceptions to enable
make: *** [out/Release/obj.target/binding/binding.o] Error 1
ERR! `make` failed with exit code: 2
ERR! not ok

Most helpful comment

@mojodna Ok so I just confirmed that this indeed enables C++ exceptions:

{
  'targets': [
    {
      'target_name': 'bindings',
      'sources': [ 'bindings.cc' ],
      'cflags!': [ '-fno-exceptions' ],
      'cflags_cc!': [ '-fno-exceptions' ],
      'conditions': [
        ['OS=="mac"', {
          'xcode_settings': {
            'GCC_ENABLE_CPP_EXCEPTIONS': 'YES'
          }
        }]
      ]
    }
  ]
}

I'm gonna close, reopen if you're still having troubles.

All 15 comments

Hey @mojodna. So the -fno-exceptions flag comes from node's common.gypi file. The following is supposed to negate that, try adding:

...
'cflags!': [ '-fno-exceptions' ],
'cflags_cc!': [ '-fno-exceptions' ]
...

The ! at the end is supposed to make sure that that flag is not used. Let me know if that works.

The _real_ solution however would be to remove all instances of C++-style throw statements. That's what I did for node-ffi, but I'm sure that won't be possible for every module.

Also it looks like you are on OS X, so try also negating this entry (change it to YES): https://github.com/joyent/node/blob/2e2df04b3538c83e4e3ddc81308ca1bde3d80fc6/common.gypi#L142

@mojodna Ok so I just confirmed that this indeed enables C++ exceptions:

{
  'targets': [
    {
      'target_name': 'bindings',
      'sources': [ 'bindings.cc' ],
      'cflags!': [ '-fno-exceptions' ],
      'cflags_cc!': [ '-fno-exceptions' ],
      'conditions': [
        ['OS=="mac"', {
          'xcode_settings': {
            'GCC_ENABLE_CPP_EXCEPTIONS': 'YES'
          }
        }]
      ]
    }
  ]
}

I'm gonna close, reopen if you're still having troubles.

Awesome, thanks!

@mojodna Thanks. This was useful.

Thanks for bringing up this issue @mojodna and for the solution @TooTallNate . I'm leveraging a number of libraries (cairo, graphicsmagick, and opencv) as well as stl code where c++ throw style exceptions are the norm.

@TooTallNate but I want exceptions...
They make my code modular and _a lot_ easier to manage.
Is there a way to use exceptions _without_ using C++ style throw statements?

@jmendeth You mean JavaScript exceptions?

No, I mean using exceptions in my native (i.e. C++) code.

If I can't use exceptions, I must check the return code every time, for example.
That makes the wrapper code more bug-phrone and difficult to manage.
Don't you think?

I don't really get what you're asking for. If you want C++ exceptions, use the gyp code posted above when building your addon. Otherwise they're disabled by default since that's how it is in node itself.

Yeah, I'm using your gyp code right now. But you said that:

The _real_ solution however would be to remove all instances of C++-style throw statements.

So, are you saying that the real solution would be to not use exceptions at all? :S

@TooTallNate This helped me! Thanks!

I'm having a similar problem on centos in https://github.com/electronifie/node-python/blob/master/binding.gyp. Without the reference to fno-exceptions, I get an error telling me to use it. If I do include it, I get an error saying it can't find my exception type - which comes from a known library (Python.h).

../src/py_object_wrapper.cc: In static member function ‘static v8::Local<v8::Value> PyObjectWrapper::ConvertToJavaScript(PyObject*)’:
../src/py_object_wrapper.cc:176:16: error: expected type-specifier before ‘OverflowError’
         catch (OverflowError error) {

Any ideas?

thanks for this Issues, it help me to. and I use this the exception can be works:
"cflags": ['-fexceptions'],
'cflags': ['-fexceptions'],

Here it is a more comprehensive list of flags to enable exceptions on all platforms builds:

```json
{
"conditions": [
[ "OS=='linux'", {
"cflags+": [ "-std=c++11", "-fexceptions" ],
"cflags_c+": [ "-std=c++11", "-fexceptions" ],
"cflags_cc+": [ "-std=c++11", "-fexceptions" ],
}],
[ "OS=='freebsd'", {
"cflags+": [ "-std=c++11", "-fexceptions" ],
"cflags_c+": [ "-std=c++11", "-fexceptions" ],
"cflags_cc+": [ "-std=c++11", "-fexceptions" ],
}],
[ "OS=='mac'", {
"cflags+": [ "-stdlib=libc++" ],
"xcode_settings": {
"OTHER_CPLUSPLUSFLAGS" : [ "-std=c++11", "-stdlib=libc++", "-pthread" ],
"OTHER_LDFLAGS": [ "-stdlib=libc++" ],
"GCC_ENABLE_CPP_EXCEPTIONS": "YES",
"MACOSX_DEPLOYMENT_TARGET": "10.7",
"CLANG_CXX_LANGUAGE_STANDARD":"c++11",
"CLANG_CXX_LIBRARY": "libc++"
},
}],
[
"OS=='win'", {
"cflags": [
"-Wall"
],
"defines": [
"WIN"
],
"msvs_settings": {
"VCCLCompilerTool": {
"ExceptionHandling": "2",
"DisableSpecificWarnings": [
"4244"
],
},
"VCLinkerTool": {
"LinkTimeCodeGeneration": 1,
"OptimizeReferences": 2,
"EnableCOMDATFolding": 2,
"LinkIncremental": 1,
}
}
}]
]
}

Was this page helpful?
0 / 5 - 0 ratings

Related issues

chen4393 picture chen4393  Â·  3Comments

Flimm picture Flimm  Â·  3Comments

jlchereau picture jlchereau  Â·  3Comments

good-idea picture good-idea  Â·  3Comments

andrewaustin picture andrewaustin  Â·  3Comments