New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Overriding default flags #26

Closed
tristanz opened this Issue Feb 20, 2012 · 13 comments

Comments

Projects
None yet
6 participants
@tristanz

tristanz commented Feb 20, 2012

This is likely a question born of ignorance, but is there a way to override the default flags in common.gypi?

I need to compile with RTTI enabled but node-gyp defaults to -fno-rtti. This is required to compile against boost, for instance.

@TooTallNate

This comment has been minimized.

Contributor

TooTallNate commented Feb 20, 2012

So in case you (or anyone else) is wondering, the "default flags" used when building your addon comes from node's common.gypi file.

As you can see if you scroll through that file -fno-rtti is indeed a default. So in your own gyp file, you must negate that. This involves specifying the cflags with a ! at the end, meaning "not". In the case of -fno-rtti, it's specified in the cflags_cc section, so try adding this:

...
  'cflags_cc!': [ '-fno-rtti' ]
...

Additionally, Mac builds usually have their own section to specify these flags, so you usually have to fix this twice (don't ask me why, gyp just kinda is weird in that case), so for Macs, add this (note that the "xcode_settings" name will vary depending on the flag you are enabling/disabling):

...
  ['OS=="mac"', {
    'xcode_settings': {
      'GCC_ENABLE_CPP_RTTI': 'YES'
    }
  }]
...

That should do it. For completeness sake, this is a barebones gyp file compatible with node-gyp that should have RTTI enabled:

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

Reopen if that doesn't work for you. Cheers!

@tristanz

This comment has been minimized.

tristanz commented Feb 20, 2012

Adding the following seems to solve the issue on OSX:

'conditions': [
  ['OS=="mac"', {
    'xcode_settings': { 'GCC_ENABLE_CPP_RTTI': 'YES' }
  }]
]

I cannot test on linux, but there's a Chromium example that suggests it could be:

[ 'OS=="linux" or OS=="freebsd" or OS=="openbsd" or OS=="solaris"',
  {
    'cflags_cc!': ['-fno-rtti'],
    'cflags_cc+': ['-frtti'],
  }
]
@TooTallNate

This comment has been minimized.

Contributor

TooTallNate commented Feb 20, 2012

@tristanz That looks correct to me :) Glad you got it figured out.

@tristanz

This comment has been minimized.

tristanz commented Feb 20, 2012

Terrific. Thanks!

@tristanz

This comment has been minimized.

tristanz commented Jul 27, 2012

I'm still struggling to fix this on Windows. I get an error

 error LNK2001: unresolved external symbol "void __cdecl boost::throw_exception

which seems to stem from an earlier warning:

warning C4530: C++ exception handler used, but unwind semantics are not enabled. Sp
ecify /EHsc

I tried adding the following but it doesn't seem to add /EHsc.

'msvs_settings': {
  'VCCLCompilerTool': {
    'ExceptionHandling': '2',  # /EHsc
  },
}

This is likely more node-gyp ignorance but ideas are appreciated.

@tristanz

This comment has been minimized.

tristanz commented Jul 27, 2012

Looks like default settings are different in the Release configuration. The fix is:

      'configurations': {
        'Release': {
          'msvs_settings': {
            'VCCLCompilerTool': {
              'ExceptionHandling': 1,
            }
          }
        }
      },

This seems to have changed multiple times over the last several versions.

@edhemphill

This comment has been minimized.

edhemphill commented Dec 6, 2012

Does anyone know why -fno-rtti was used as a default? Any particular reason?

@TooTallNate

This comment has been minimized.

Contributor

TooTallNate commented Dec 6, 2012

@edhemphill node-gyp uses the same configuration as when node itself it built, so the answer is because node itself doesn't need rtti.

@edhemphill

This comment has been minimized.

edhemphill commented Dec 13, 2012

thanks...

@springmeyer

This comment has been minimized.

Contributor

springmeyer commented Apr 6, 2013

I'm hitting this same issue on windows. I'm finding it impossible to override the ExceptionHandling value (which for me like @tristanz breaks my build with linking errors). The only workaround I can find (as mentioned at brianmcd/contextify#45) is to manually modify the common.gypi that node-gyp bundles from node itself.

I'm putting

          'msvs_settings': {
            'VCCLCompilerTool': {
              'ExceptionHandling': 1,
            }
          }

in my binding.gyp, trying both release and debug configurations and 'ExceptionHandling': 0 still ends up in the visual studio output file. I'm on windows 7 with node v0.10.3 and node-gyp v0.9.5 installed globally.

@springmeyer

This comment has been minimized.

Contributor

springmeyer commented Apr 6, 2013

ugh... looks like a gyp bug/complexity that may require modifying how node's common.gypi is written: https://groups.google.com/forum/?fromgroups=#!topic/gyp-developer/p98GJxYJuH4

@devrikx

This comment has been minimized.

devrikx commented Jun 23, 2014

Adding /EHsc on Windows...hope it helps - took me a little bit of trial/error and searching around.

Inside of 'target_defaults':

'configurations':
{
  'Debug':
  {
    'defines': [ 'DEBUG', '_DEBUG' ],
    'msvs_settings':
    {
        'VCCLCompilerTool':
        {
            'RuntimeLibrary': 3, # shared debug
            'ExceptionHandling': 1,     # /EHsc  doesn't work.
            '/EHsc' # Enable unwind semantics for Exception Handling.  This one actually does the trick
            # this is also where you can put /GR or /MDd, or other defines.
        }
    }
  },
  'Release':
  {
        'VCCLCompilerTool':
        {
            'RuntimeLibrary': 2, # shared release
            'ExceptionHandling': 1,     # /EHsc  doesn't work.
            '/EHsc' # Enable unwind semantics for Exception Handling.  This one actually does the trick
            # this is also where you can put /GR or /MD, or other defines.
        }
  }
}

Example using node-gyp to build MySQL C++ Connector, overriding defaults. It uses C++ Exception Handler and so as you will see the warning has been suppressed because unwind semantics are now enabled:

image

EDIT: Closed the code block fence
EDIT 2: Adding why
WHY: Because this issue shows up on Google as #1 for me for a couple of different things I've had to search for...this puts the answers I've found here -> I realize this issue is closed sorry for confusion.

simonmcmanus added a commit to simonmcmanus/avro-nodejs that referenced this issue Apr 16, 2015

TheThing added a commit to TheThing/sharp that referenced this issue Jul 25, 2015

binding.gyp: Fix warnings during compiling
Fixes the following warnings while compiling:

```
D:\Forritun\Microsoft Visual Studio 14.0\VC\include\xlocale(341): warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc (compiling source file ..\src\common.cc) [D:\sharp\build\sharp.vcxproj]
D:\Forritun\Microsoft Visual Studio 14.0\VC\include\xlocale(341): warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc (compiling source file ..\src\operations.cc) [D:\sharp\build\sharp.vcxproj]
...etc...
```

Solution taken from here: nodejs/node-gyp#26 (comment)
@ben-kirk

This comment has been minimized.

ben-kirk commented Nov 1, 2016

I've tried all the things listed here and in #857, but I still can't get RTTI enabled in my auto-generated MSVS 2015 project. Here is my binding.gyp below (Oh, I'm using nbind with Electron). I have all the methods I've tried listed in this file contents below, but I also tried them separately to no avail...


{
    'targets': [
        {
            'includes': [
                'auto.gypi'
            ],
      'sources': [
        'addon.cc'
      ],
      'cflags_cc!': [
        '-fno-rtti'
      ],
      'conditions': 
      [
        [
          'OS=="mac"',
          {
            'xcode_settings': { 'GCC_ENABLE_CPP_RTTI': 'YES' }
          },
        ],
        [
          'OS=="win"',
          {                        
            'cflags': [
                '/GR',
              ],
            'configurations': {
              'Debug': {
                'msvs_settings': {
                  'VCCLCompilerTool': {
                    'RuntimeTypeInfo': 'true',
                    'AdditionalOptions': ['/GR'], 
                  }
                }
              },
              'Release': {                            
                'msvs_settings': {
                  'VCCLCompilerTool': {
                    'RuntimeTypeInfo': 'true',
                    'AdditionalOptions': ['/GR'],
                  }
                }
              }
            }
          }
        ]
      ],
      'defines': [
        '_WIN32_WINNT=0x0601'
      ],
      'include_dirs': [
        'C:/Program Files/boost/boost_1_62_0'
      ],        
      'link_settings': {
        'library_dirs': [
          'C:\\Program Files\\boost\\boost_1_62_0\\lib64-msvc-14.0'
        ]  
      }
        }
    ],
  'includes': [
    'auto-top.gypi'
  ]
}

erikvullings added a commit to TNOCS/rvo2 that referenced this issue Feb 21, 2017

Moved the original source files to src folder. Added compiler instruc…
…tion to deal with exception handling (getting rid of /EHsc warning)

See also nodejs/node-gyp#26

skelliam added a commit to skelliam/node that referenced this issue Sep 2, 2018

Remove /MP from common.gypi
Forcing this option makes the option ```MultiProcessorCompilation``` in ```msvs_settings``` useless.  It also means that one cannot use ```#import``` or they will be faced with this error when trying to build:

```
error C2813: #import is not supported with /MP (compiling source file...)
```

Please see additional discussion of this here:  nodejs/node-gyp#1087
and here: nodejs/node-gyp#26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment