Skip to content

Overriding default flags #26

Closed
Closed

Description

@tristanz

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.

Activity

  1. TooTallNate commented on Feb 20, 2012

    @TooTallNate
    Contributor

    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!

  2. tristanz commented on Feb 20, 2012

    @tristanz
    Author

    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'],
      }
    ]
  3. TooTallNate commented on Feb 20, 2012

    @TooTallNate
    Contributor

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

  4. tristanz commented on Feb 20, 2012

    @tristanz
    Author

    Terrific. Thanks!

  5. tristanz commented on Jul 27, 2012

    @tristanz
    Author

    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.

  6. tristanz commented on Jul 27, 2012

    @tristanz
    Author

    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.

  7. edhemphill commented on Dec 6, 2012

    @edhemphill

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

  8. TooTallNate commented on Dec 6, 2012

    @TooTallNate
    Contributor

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

  9. edhemphill commented on Dec 13, 2012

    @edhemphill

    thanks...

  10. springmeyer commented on Apr 6, 2013

    @springmeyer

    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.

  11. springmeyer commented on Apr 6, 2013

    @springmeyer

    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

  12. kirvedx commented on Jun 23, 2014

    @kirvedx
    Contributor

    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.

  13. ben-kirk commented on Nov 1, 2016

    @ben-kirk

    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'
      ]
    }
    
  14. added a commit that references this issue on Sep 2, 2018
  15. KrishnaPG commented on Mar 11, 2020

    @KrishnaPG

    For the /EHsc issue, with VS Build Tools 2017 and node v12.9.1 the below worked in the bindings.gyp:

      "targets": [
        {
          "target_name": "addon",
          "cflags!": [ "-fno-exceptions" ],
          "cflags_cc!": [ "-fno-exceptions" ],
          "sources": [ "addon.cc" ],
          "include_dirs": [
            "<!@(node -p \"require('node-addon-api').include\")"
          ],
          'defines': [ 'NAPI_DISABLE_CPP_EXCEPTIONS' ],
    
          'msvs_settings': {
              'VCCLCompilerTool': {
                'ExceptionHandling': '1',    
                'AdditionalOptions': ['/EHsc']
              }
          }
    
        }
    

    Sharing here in case anyone facing the same problem:

    warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc (compiling source file
     ..\addon.cc) [..\build\addon.vcxproj]
    
  16. added a commit that references this issue on Sep 8, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions