Problems with C++ modules (dbus in particular)

[Ivshti]

After running "npm install dbus" (from the same Node.js version as node-webkit: v0.8.4), I get this error

[0815/200414:INFO:CONSOLE(485)] "Uncaught Error: /tmp/nw_release_linux_x32/hello-world/node_modules/dbus/lib/dbus.node: undefined symbol: _ZN4node14no_deprecationE", source: module.js (485)

On the other hand, other C++ modules (e.g. mongodb with native bson) worked.

[zcbenz]

node.js was built as static library and some symbols in it were not exported by default (not with -rdynamic switch), we only did it for V8.

Thanks for reporting it, it will be fixed in next release.

[zcbenz]

Oops, this issue was mistakingly closed, reopen it now.

[Ivshti]

I updated to v0.2.2, and now I get this:
"ev_default_loop_ptr"
It seems that libev is not built with -rdynamic now.

I haven't tried with any other C++-based modules beside D-bus (npm install dbus), but I think only non-async ones may work (not linked to libev).

If you don't plan releasing soon, please explain how to add those switches myself. Thanks.

[zcbenz]

Are you using the Linux version?

[Ivshti]

Yes, 32 bit.

BTW, a workaround: installing standalone libev and passing it as LD_PRELOAD seemed to work (but the process froze, but this is a node-dbus issue since I also have problems with it on pure node so it's not related to this project).

[zcbenz]

When I fix it I'll release a 0.2.3-pre version for your use.

[Ivshti]

Thanks, that is awesome.

[zcbenz]

@Ivshti would Chromium's desktop notification (webkitNotifications API) satisfies your use? I'm thinking of dropping support for node C++ modules.

[itdaniher]

Waiting for C++ modules myself, to use node-webkit with node-usb.

[zcbenz]

@itdaniher Which platform are you using? win32 or OS X or Linux 32bit or Linux 64bit? Could Chromium USB API satisfy your use?

[rogerwang]

I don't think we can find a substitute in Chrome for every missing node C++
modules. And Node's strong native support is one of the reasons we started
this project in the first place.

Roger

On Sun, Aug 26, 2012 at 11:30 AM, Zhao Cheng notifications@github.comwrote:

@itdaniher https://github.com/itdaniher Which platform are you using?
win32 or OS X or Linux 32bit or Linux 64bit? Could Chromium USB APIhttp://www.chromium.org/developers/design-documents/extensions/proposed-changes/apis-under-development/usb-apisatisfy your use?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/20#issuecomment-8029861.

[zcbenz]

@itdaniher node-usb didn't support node v0.8.x and its npm package is totally broken. I'm afraid it's not possible to run it in node-webkit.

[Ivshti]

Yes, that is another problem. node-dbus does not support v0.8.x either. Usually, when I stumble upon a module like this, I report it upstream immediately. But it could be months before it gets fixed.

A version of node-webkit compiled with node v0.6.x and all the shared symbols done properly would be a super-powerful tool. I presume that would be difficult because the APIs/interfaces used to merge it with the Chromium event loop work differently?

[rogerwang]

Hello Ivo,

node-webkit integrates Node and Chromium Webkit in the same thread so that
the function call between them would be efficient. But I don't think it
will break Node modules. We intend to support all the modules running on
Node.

We are looking into this bug with a high priority and will keep you posted.

Roger

On Sun, Aug 26, 2012 at 4:35 PM, Ivo Georgiev notifications@github.comwrote:

Yes, that is another problem. node-dbus does not support v0.8.x either.
Usually, when I stumble upon a module like this, I report it upstream
immediately. But it could be months before it gets fixed.

A version of node-webkit compiled with node v0.6.x and all the shared
symbols done properly would be a super-powerful tool. I presume that would
be difficult because the APIs/interfaces used to merge it with the Chromium
event loop work differently?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/20#issuecomment-8031318.

You may say I am a dreamer, but I am not the only one.

[zcbenz]

@Ivshti can the node-dbus compiled with node v0.6.x run in node v0.8.x? I'm not sure whether the ABI has changed.

Providing a node-webkit with node v0.6.x will double the binaries we need to provide, I don't think it is a good idea.

[Ivshti]

But, is changing the Node version a simple change to make? If it is, you can just put some simple instructions on how to change it and users might compile their own version.

The most important change is the migration from libev to libuv, and I am not sure if it is because of that, but node-dbus compiled for 0.6 does not work on 0.8 (crashes with wrong arguments to a libdbus function). Re-compiling it does not work either, since the libev API has changed.

[zcbenz]

The node used by node-webkit is already heavily modified to make it more fit for embedding, maintaining both v0.6 and v0.8 branch would be a disaster.

I suggest you patching node-dbus yourself, there are only a few calls to libev in ndbus-connection-setup.cc, it's easy to replace them with the libuv equivalent.

[zcbenz]

btw, can you paste the error you got when using node-dbus under v0.8? According to your description ("crashes with wrong arguments to a libdbus function") it didn't seem to be fault of node.

[Ivshti]

Using this code:

#!/usr/bin/node
var dbus = require("dbus");
process.nextTick(function()
{
    dbus.init();
    libnotify = dbus.get_interface(dbus.session_bus(),"org.freedesktop.Notifications","/org/freedesktop/Notifications","org.freedesktop.Notifications");
    libnotify.Notify("", 0, "", "testing notif", "testing notification", [], {}, -1); 
});

All works with node 0.6.17; upgrade to 0.8.4, and this error appears:
process 19835: arguments to dbus_message_new_method_call() were incorrect, assertion "_dbus_check_is_valid_path (path)" failed in file dbus-message.c line 1202.
This is normally a bug in some application using the D-Bus library.
D-Bus not built with -rdynamic so unable to print a backtrace
Aborted (core dumped)

Downgrade back to 0.6, everything works. I use Shouqun's node-dbus, it was more difficult to modify for libuv. Anyway, I am currently trying out a native implementation (https://github.com/sidorares/node-dbus), since it's more reliable (avoids possible API/ABI changes) and really (IMO) reduces all the wrapper-bloat between libdbus and V8 (and much more fun to hack on since it's raw protocol).

I will try out Motorola-Mobility's DBus module, since I see you referenced it's source. It seems to have a terrible API (low-level), but wrapping it with proxies and introspection should be like a 20 minute job, so if it works it would be great.

Edit: absolutely same problems as with Shouqun's module. The compile-time errors are the same (libev API problems), and if I use the pre-compiled with 0.6 version, I get
node: symbol lookup error: /tmp/other-dbus/node-dbus/build/Release/ndbus.node: undefined symbol: _ZNK2v85Value11IsUndefinedEv

I think I would work on the native DBus module :)

But, when any of the node-dbus modules gets official 0.8 support, I would test them out with node-webkit, since C++ support is pretty important for my projects anyway.

[zcbenz]

@Ivshti Can you test if node-webkit v0.2.3 still has the "undefined symbol" error?

[Ivshti]

Nope, everything works great. That is, with a simple non-async module I wrote for Node v0.6. now I will test with some other modules, e.g. node-taglib. As for dbus, it's not node-webkit's problem, but the native DBus implementation will, with a quick addition of proxies & introspection, be able to emulate the API of Shouqun's version.

[Ivshti]

Now, node-taglib tests.

Compiled with 0.6, running on NW: crashes with no error messages. Compiled with 0.6, running with node 0.8, some fancy undefined symbols.
node: undefined symbol: _ZN2v814ObjectTemplate11SetAccessorENS_6HandleINS_6StringEEEPFNS1_INS_5ValueEEENS_5LocalIS2_EERKNS_12AccessorInfoEEPFvS7_NS6_IS4_EESA_ES5_NS_13AccessControlENS_17PropertyAttributeE

Compiled with 0.8 (as it should be), on NW: running great, on Node 0.8: running great.
So I guess everything here is working awesome, maybe except error reporting :)

And that proves that 0.6 and 0.8 are ABI-incompatible.

And btw, node-dbus does the same. Trying to run the module compiled with 0.6 under 0.8 with Node, it gives an error. On NW, it hangs completely without error messages.

[zcbenz]

Very good, thanks for your investigation.

[Ivshti]

Node-webkit v0.2.4 (pre-built, Linux 32 bit), with LevelDB compiled (&tested) for Node 0.8.4:
undefined symbol: _ZN4node6Buffer11HasInstanceEN2v86HandleINS1_5ValueEEE"

Node-webkit v0.2.5pre (my own build, target "Release") with LevelDB compiled (&tested) for Node 0.8.4:
undefined symbol: _ZN2v86Object3HasEj"

Isn't there a way to automatically find all missing symbols and fix them?

[zcbenz]

Can you have a try on v0.2.3 and paste the output? I need to make sure whether this is a new bug or a previous bug.

And are you using node-leveldb?

[Ivshti]

Yes, I would, but I do not have v0.2.3. Can you provide a link?
I am using the leveldb I get through "npm install leveldb". This is the github repo: https://github.com/my8bird/node-leveldb

[zcbenz]

v0.2.3 can be downloaded at:
http://s3.amazonaws.com/node-webkit/v0.2.3/nw_release_linux_x32.tar.gz

[Ivshti]

node-webkit v0.2.3, same leveldb module:
undefined symbol: _ZN4node6Buffer11HasInstanceEN2v86HandleINS1_5ValueEEE

[zcbenz]

Can you sync your local code to newest upstream? I'm pretty sure your code is before the photoionization/build_chromium@61bf507, which included some critical fixes.

Edited:
And node-leveldb runs well on my newest build.

[zcbenz]

I've added a chapter on updating code in Wiki:
https://github.com/rogerwang/node-webkit/wiki/Building-node-webkit

[Ivshti]

My common.gypi has all those changes. Obviously, I have built something wrong.

[zcbenz]

I suggest deleting the out directory and have a rebuild. And is v0.2.5 working for you?

[zcbenz]

@Ivshti can I close this issue?

[Ivshti]

I did not test levelDB with the latest patches because I already did what I wanted without levelDB, so if it works for you, I guess the issue is closed.