Re: [nodejs] AddOns that dynamically load Shared Libraries (*.so)

[Ben Noordhuis]

On Tue, Jan 8, 2013 at 5:29 AM, Benjamin Farrell <bengf...@gmail.com> wrote:
> Hey everyone - I'm trying to bind Node.js to the OpenNI project
> (http://www.openni.org/). I'm coming at this having not really used much
> C++, let alone the Node build system.
>
> Anyway - I have been able to create a custom AddOn for Node via Gyp. It
> loads the proper shared libraries compiles just fine. I can even load the
> module - but it crashes on an exception. The exception is coming from the
> OpenNI project - however, before I post to that group, I wanted to check
> here.
>
> The reason I wanted to check here, is that the exception comes when the
> shared libraries themselves load yet ANOTHER .so file for the device driver.
> It seems to be failing when trying to execute and initialize that shared
> library.
>
> So my question is - is there anything in Node that prevents this behavior?
> Perhaps some kind of sandbox, or lockout, or something that prevents shared
> libraries from loading and executing other libraries loaded at runtime?
>
> Thanks! Again, sorry if it's a silly question - all of this C++ really
> isn't my style yet, and I'm just getting my feet wet,

Nothing I can think of. Native add-ons are loaded with
dlopen(RTLD_LAZY) and that's it, no special processing or handling.

[Benjamin Farrell]

Awesome, I appreciate it!  Onto the OpenNI forums!  If anybody knows otherwise I'd love to hear it so I'm not banging my head against the wall needlessly.  And honestly this is great news - I'm glad it wasn't what I was afraid of - that this wasn't going to be possible in Node for some silly reason.

[Ben Noordhuis]

On Tue, Jan 8, 2013 at 3:22 PM, Benjamin Farrell <bengf...@gmail.com> wrote:
> Awesome, I appreciate it! Onto the OpenNI forums! If anybody knows
> otherwise I'd love to hear it so I'm not banging my head against the wall
> needlessly. And honestly this is great news - I'm glad it wasn't what I was
> afraid of - that this wasn't going to be possible in Node for some silly
> reason.

There's one thing to keep in mind if the exceptions you mentioned are
C++ exceptions: node.js itself doesn't use them - and is in fact
compiled with -fno-rtti -fno-exceptions - so you need to catch any and
all exceptions that library code throws. If you let one through,
node.js (or rather, the C++ runtime) will abort.

I didn't think of it yesterday, but if OpenNI throws an exception at
dlopen() time (e.g. from a static constructor), it's game over. That
would be a moronic thing to do, though. For one, you'd almost
certainly leave the dynamic linker in an undefined state.

[Benjamin Farrell]

I think they are handling things pretty well.  The only reason I get as much info on the error as I do is that they provide a method to print out a detailed explanation why the initialization object is null or invalid - and I printf that.

So, I think whatever is happening on or around the dlopen is handled gracefully on error - it's just a mystery why it's not loading/instantiating.

thanks again!

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

[Ben Farrell]

Ben, thanks so much for the help - I finally seem to have gotten things
working (or they appear to be). It was a matter of not really knowing
what I was doing in Gyp, and was linking to my files wrong. I finally
ended up building verbosely and comparing what g++ was doing for each
project and just throwing the arguments I was missing into the libraries
array in the "binding.gyp" file, and it all worked!

thanks again! Still not QUITE sure how it's all linking, but I have
more of a clue now. Despite the frustration, I learned a lot for a noob
to all of this! Working as well as it did seemed to be a red herring,
oh well

Before:
"targets": [
{
"target_name": "proj",
"sources": [ "proj.cpp" ],
"include_dirs": [ "./Include"],
"libraries": ["../shared/libOpenNI2.so"]
}

After:

"targets": [
{
"target_name": "proj",
"sources": [ "proj.cpp" ],
"include_dirs": [ "./Include"],
"libraries": ["-lOpenNI2", "-Wl,-rpath ./"]