Skip to content
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

Does nad no longer work with node? (appears to want iojs) #5

Open
mateodelnorte opened this issue Mar 10, 2015 · 13 comments
Open

Does nad no longer work with node? (appears to want iojs) #5

mateodelnorte opened this issue Mar 10, 2015 · 13 comments

Comments

@mateodelnorte
Copy link

Hi Thorsten,

Trying to dive into some addon debugging with nad and getting this:

✗ nad build
info nad Injecting code into node source, then rebuilding it
(cd /Users/matt/electronifie/node-quickfix/ && curl -L https://github.com/iojs/io.js/archive/v0.10.36.tar.gz | tar xvf -)
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   120    0   120    0     0    767      0 --:--:-- --:--:-- --:--:--   769
100     9  100     9    0     0     29      0 --:--:-- --:--:-- --:--:--    29
tar: Unrecognized archive format
tar: Error exit delayed from previous errors.
make: *** [/Users/matt/electronifie/node-quickfix/node-0.10.36] Error 1
failed with code=2

I'm developing an addon on 10.36 using mainline node. Is that no longer possible with nad?

@thlorenz
Copy link
Owner

Ah this is odd and definitely a regression. Could you try with older minor version to confirm that this was introduced with the latest update?

npm install -g nad@0.1

I'm guessing it's not properly detecting that you're using joyent/node. Most likely due to a but around here

Do you mind refiling the second part with nad-bindings to discuss this over there?
AFAIK it's intended to not look inside node_modules for its own binding file. I.e. node-gyp is expected to run from the dir into which the addon was installed.

@mateodelnorte
Copy link
Author

Updated issue and moved 2nd portion to nad-bindings. Testing above.

nad build appears to be doing it's job on v0.1.x. It's currently compiling away.

Thx.

@mateodelnorte
Copy link
Author

Looks like things compile, but don't link correctly. I'm guessing this is a problem with my setup?

  NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
  "non-virtual thunk to std::__1::basic_iostream<char, std::__1::char_traits<char> >::~basic_iostream()", referenced from:
      construction vtable for std::__1::basic_iostream<char, std::__1::char_traits<char> >-in-std::__1::basic_stringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> > in FixAcceptor.o
      construction vtable for std::__1::basic_iostream<char, std::__1::char_traits<char> >-in-std::__1::basic_stringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> > in FixInitiator.o
  "non-virtual thunk to std::__1::basic_iostream<char, std::__1::char_traits<char> >::~basic_iostream()", referenced from:
      construction vtable for std::__1::basic_iostream<char, std::__1::char_traits<char> >-in-std::__1::basic_stringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> > in FixAcceptor.o
      construction vtable for std::__1::basic_iostream<char, std::__1::char_traits<char> >-in-std::__1::basic_stringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> > in FixInitiator.o
  "non-virtual thunk to std::__1::basic_istream<char, std::__1::char_traits<char> >::~basic_istream()", referenced from:
      construction vtable for std::__1::basic_istream<char, std::__1::char_traits<char> >-in-std::__1::basic_stringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> > in FixAcceptor.o
      construction vtable for std::__1::basic_istream<char, std::__1::char_traits<char> >-in-std::__1::basic_stringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> > in FixInitiator.o
  "non-virtual thunk to std::__1::basic_istream<char, std::__1::char_traits<char> >::~basic_istream()", referenced from:
      construction vtable for std::__1::basic_istream<char, std::__1::char_traits<char> >-in-std::__1::basic_stringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> > in FixAcceptor.o
      construction vtable for std::__1::basic_istream<char, std::__1::char_traits<char> >-in-std::__1::basic_stringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> > in FixInitiator.o
  "non-virtual thunk to std::__1::basic_ostream<char, std::__1::char_traits<char> >::~basic_ostream()", referenced from:
      construction vtable for std::__1::basic_ostream<char, std::__1::char_traits<char> >-in-std::__1::basic_stringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> > in FixAcceptor.o
      construction vtable for std::__1::basic_ostream<char, std::__1::char_traits<char> >-in-std::__1::basic_stringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> > in FixInitiator.o
  "non-virtual thunk to std::__1::basic_ostream<char, std::__1::char_traits<char> >::~basic_ostream()", referenced from:
      construction vtable for std::__1::basic_ostream<char, std::__1::char_traits<char> >-in-std::__1::basic_stringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> > in FixAcceptor.o
      construction vtable for std::__1::basic_ostream<char, std::__1::char_traits<char> >-in-std::__1::basic_stringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> > in FixInitiator.o
  "non-virtual thunk to std::__1::basic_iostream<char, std::__1::char_traits<char> >::~basic_iostream()", referenced from:
      construction vtable for std::__1::basic_iostream<char, std::__1::char_traits<char> >-in-std::__1::basic_stringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> > in FixAcceptor.o
      construction vtable for std::__1::basic_iostream<char, std::__1::char_traits<char> >-in-std::__1::basic_stringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> > in FixInitiator.o
  "non-virtual thunk to std::__1::basic_iostream<char, std::__1::char_traits<char> >::~basic_iostream()", referenced from:
      construction vtable for std::__1::basic_iostream<char, std::__1::char_traits<char> >-in-std::__1::basic_stringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> > in FixAcceptor.o
      construction vtable for std::__1::basic_iostream<char, std::__1::char_traits<char> >-in-std::__1::basic_stringstream<char, std::__1::char_traits<char>, std::__1::allocator<char> > in FixInitiator.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[3]: *** [/Users/matt/development/electronifie/electronifie/node-quickfix/node-0.10.36/out/Debug/node] Error 1
make[2]: *** [node_g] Error 2
make[1]: *** [/Users/matt/electronifie/node-quickfix/node-0.10.36//out/Debug/node_g] Error 2
make: *** [build] Error 2
failed with code=2

@thlorenz
Copy link
Owner

Yeah that last one is not a nad issue. I don't know what FixAcceptor is but that seems to be the origin of your problem.
You could try to just node-gyp rebuild. If I'm not mistaken you should have the same issue.

@thlorenz
Copy link
Owner

nad build appears to be doing it's job on v0.1.x

We need to figure out what's happening here. My intent was not to only support io.js with the latest nad version.
I'll try to find some time to investigate what's going on.

Are you able to reproduce the problem by just doing the below with node 0.10?

nad init test-nad && cd test-nad
nad configure
nad build

And what about with node 0.12?

@mateodelnorte
Copy link
Author

Doing the simple sample, as above, works fine with node v0.10 and nad 0.1.

Doing the same with node v0.12 and nad 0.2.1 gave me:

info nad Injecting code into node source, then rebuilding it
(cd /Users/matt/development/scratch/test-nad/ && curl -L https://github.com/iojs/io.js/archive/v0.12.0.tar.gz | tar xvf -)
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   119    0   119    0     0    788      0 --:--:-- --:--:-- --:--:--   793
100     9  100     9    0     0     32      0 --:--:-- --:--:-- --:--:--    32
tar: Unrecognized archive format
tar: Error exit delayed from previous errors.
make: *** [/Users/matt/development/scratch/test-nad/node-0.12.0] Error 1
failed with code=2

node v0.12 and nad v0.1 completes correctly.

@thlorenz
Copy link
Owner

Thanks I'll investigate this once I have some time. Could be something rather simple. It just doesn't correctly detect that you're using node.js instead of io.js.

@mateodelnorte
Copy link
Author

So back to the compile problem. node-gyp rebuild finishes successfully for me, but nad build fails. Based on the output format, I'd guess it's using a different compiler. Any tips on how to isolate the problem and fix?

@mateodelnorte
Copy link
Author

Perhaps something to note is that my bindings file has some include_dirs and flags to take into account:

'include_dirs': [
        "<!(node -e \"require('nan')\")",
        '/usr/local/include',
        '/usr/local/include/quickfix',
        '/usr/local/include/tbb'
      ],
      'cflags': [ '-fexceptions', '-std=c++11' ],
      'cflags!': ['-fno-exceptions', '-fno-rtti'],
      'cflags_cc': [ '-fexceptions' ],
      'cflags_cc!': [ '-fno-exceptions', '-fno-rtti' ],
      'conditions': [
        ['OS=="mac"', {
          'xcode_settings': {
            'GCC_ENABLE_CPP_EXCEPTIONS': 'YES',
            'GCC_ENABLE_CPP_RTTI': 'YES',
            "OTHER_CFLAGS": ["-mmacosx-version-min=10.7", "-stdlib=libc++"]
          }
        }]
      ]

Is there anything special I need to do, to have nad take them into account as well?

@thlorenz
Copy link
Owner

This is really hard to trouble shoot without an actual example that I can compile.
Is it possible for you to pull out the minimum required to reproduce your issue and throw this up on github?
Also look in your .nadconfig and ensure you're using the same compiler and linker that is used by node-gyp. You can change the compiler by editing that file or rerunning nad configure with the appropriate args.
Most likely it's using clang and it should.

Another thing to investigate is if node-gyp works when building in Debug mode as you're currently building in Debug mode with nad (which it does by default).
You could try to build in Release mode (i.e. from Xcode) or via make -C out/Release.

The pain point here is that node changed the way you configure the build mode from 0.10 to 0.12.
Look inside the Makefile inside your node dir to learn more.

@mateodelnorte
Copy link
Author

If you have time to give it a shot (would appreciate it much!), I'm just doing nad build against the master branch of https://github.com/electronifie/node-quickfix. The only other thing that's changed is the require() for the module's .node file to use nad-bindings, at the top of index.js, and of course having run nad configure.

I've tried specifying g++ and others, but I'm pretty sure node-gyp is using clang when I build the module.

Currently going through the Makefile to try to figure out how to build in debug mode. npm rebuild and npm link have been building in Release mode successfully.

@thlorenz
Copy link
Owner

I can try to find some time although not sure how soon I can get enough to seriously have a look especially since I'll have to install some external libs to make this work.

@mateodelnorte
Copy link
Author

Ah, yes. Sorry forgot to mention that: https://github.com/electronifie/node-quickfix/blob/master/README.md, http://www.quickfixengine.org/quickfix/doc/html/building.html

If you do get time, thanks a bunch in advance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants