Switch to libudev.so.1 [$50]

[katanacrimson]

As per my comment in #701 and numerous comments in the related issue LightTable/LightTable#161 about the problem and how symlinking is _NOT_ a fix, and how distributions are no longer shipping with a stale version of libudev, the dependency needs to be updated to track changes to maintain support with modern distros.

Additionally, claiming that distros "should ship with libudev.so.0" is a bad point; that version is on life support to allow currently-maintained software to adapt and move over to the new version. That means this software needs to be updated to move over as well before the old version of the library is no longer maintained and removed entirely (which is already happening in stable distros).

There is a $50 open bounty on this issue. Add to the bounty at Bountysource.

[rogerwang]

I agree with you that symlinking is not a fix. It's workaround provided for systems shipping only libudev.so.1

And yes, applications are supposed to move to newer version of library APIs eventually (and we'll follow our upstream when they do the move) but that needs time. For distributions just breaking backwards compatibility is not a good behavior. But that's not a topic for node-webkit issues discussion.

[katanacrimson]

I've updated the associated wiki page to indicate that what is provided is not a fix, but a stopgap measure for development / testing purposes; hopefully that'll discourage developers from thinking it'll be okay to use symlinks on client/user systems (especially ones they do not own) and causing problems for users needlessly.

https://github.com/rogerwang/node-webkit/wiki/The-solution-of-lacking-libudev.so.0

I've also added a list of currently affected distributions to the page. I'm sure there's others right now too - I doubt debian and RHEL are affected, but what of others such as CentOS, Scientific Linux, OpenSUSE...?

In any case, this does put a hamper into plans for my own project, but I've got quite a bit of work to do on that end anyways. I myself will be affected by this problem though, as I'm running Arch, which seems to have ditched the .0 so quite a while ago.

[rogerwang]

The linux binary provided by us is not a good solution for linux distributions. Ideally there should be distro-native linux packages for node-webkit, as well as package builder tool for application developers. But we don't have time to work on it. Contribution on this will be much appreciated.

[katanacrimson]

Have you considered leveraging something like opensuse's OBS? That may be worthwhile for mainstream distro support.

[szwacz]

Can you please explain problem with libudev in more details?
What is the purpose of this library?
This is Chromium or NW problem?
Switching to libudev.1 simply requires a lot of code to rewrite or something else is going on here?
The date of resolving this issue is completely unknown?

Thank you for clarification!

[maksimr]

This really is an awful solution and should be reconsidered - and actually fixed.

+1

[rogerwang]

One of the purpose of this library is to detect pluggable devices which Chrome could use like USB webcam.
It's a Chromium problem.
I believe upstream is not switching to libudev.so.1 because they want to support old distributions as well.

[edi9999]

I've updated the section

Modify the binary yourself

to be less scary:

from :

sed -i 's/\x75\x64\x65\x76\x2E\x73\x6F\x2E\x30/\x75\x64\x65\x76\x2E\x73\x6F\x2E\x31/g' nw

to:

sed -i 's/udev\.so\.0/udev.so.1/g' nw

By the way, shouldn't this be the recommended way of making it work ?

[katanacrimson]

@edi9999 Just because you can replace a dependency in the binary doesn't mean it's the wisest thing to do. It may or may not create minor, major, or critical issues throughout the application. That's why it's versioned in the first place. All of the listed "solutions" are shims for the time being, until upstream (which is still relying on the older libudev themselves) moves to libudev.so.1.

[szwacz]

It looks like both hacks from wiki (local symlink, or editing the binary) are about faking the new lib to look like it is the old one. So why actually editing the binary is more risky than the other solution?

[katanacrimson]

They're all risky. That's why I'm calling them shims.

[retrohacker]

So, if you are comfortable with the possible instability of nodewebkit after patching the executable, I've created a wrapper script for your app that will automagically patch nodewebkit if needed. Simply make this your bin in package.json and you are good to go.

https://gist.github.com/wblankenship/574d6263b3f6c55b94db

It is (almost) completely transparent for your users.

[gravitybacklight]

it looks as though the switch in chromium was targeted for M41, but has now made it into main:
https://code.google.com/p/chromium/issues/detail?id=415212
https://codereview.chromium.org/674703002/#ps140001

[nitriques]

+1 On this. Was not working on Ubuntu 14.

Linking .0 to .1 seems to does the trick. See http://askubuntu.com/questions/288821/how-do-i-resolve-a-cannot-open-shared-object-file-libudev-so-0-error

[sarciszewski]

This is blocking adoption for me. :(

[shaynem]

sed -i
's/\x75\x64\x65\x76\x2E\x73\x6F\x2E\x30/\x75\x64\x65\x76\x2E\x73\x6F\x2E\x31/g'
/path/to/nwjs

That works a treat for us and we run it on each deploy, it doesn't cause us
any troubles but best to test with your own.

The linking is allot harder because of different variations i386 / x86_64
plus different distribution paths.. sure you can write a install script to
handle all these scenarios however if you get can away with the above sed
command then you can skip all that.

On Sun, May 17, 2015 at 5:51 PM, Scott Arciszewski <notifications@github.com

wrote:

This is blocking adoption for me. :(

—
Reply to this email directly or view it on GitHub
#770 (comment).

[sarciszewski]

The problem is more: I want to just be able to install the damn software and hit the ground running. Creating symlinks or rewriting binaries (either on disk or at runtime) is NOT an acceptable solution.

[baconbrad]

Sorry this free software built with the hard work of many contributors working in their free time failed to meet your expectations.

[sarciszewski]

@baconface Fuck off with your passive aggressive attitude. It's not helpful.

Everyone else: I'm posting a bounty on actually solving this issue.

[katanacrimson]

@baconface Thank you for playing a key part in marketing Open Source software. We'll definitely win over customers from proprietary software in no time with help like yours.

@sarciszewski From what I thought I noticed, electron (formerly atom shell) didn't seem to have this issue. If you need something ASAP, I'd suggest steering that way.

[sarciszewski]

I'm going to muck with chromium and see if I can patch this upstream. It's kind of ridiculous that this is still broken 2 years later. (Not to blame anyone, it's not an easy problem to solve.)

[ssokolow]

As a temporary fix, it is possible to bundle a copy of libudev.so.1 from an older Ubuntu .deb and write a launcher script which sets LD_LIBRARY_PATH, much like many games do for other libraries.

libudev is LGPL licensed and the source is tiny enough that bundling the source tarball in with the nw.js app is a perfectly reasonable way to satisfy said license.

[karolherbst]

is there any status update on this? Because I might have some time to work on this.

[rogerwang]

Chromium upstream has fixed it: https://bugs.chromium.org/p/chromium/issues/detail?id=415212

The fix is in 0.13.0.