komanda
komanda copied to clipboard
mephux
Linux libudev link issue / General Linux Startup Issues
Running results in following error:
./Komanda: error while loading shared libraries: libudev.so.0: cannot open shared object file: No such file or directory
I believe the issue is related to this but putting symbolic links anywhere doesn't work, no matter where I put them. Since this is all built rather than running node-webkit manually, I don't know how to work around this.
@eugene-bulkin looks like it's a know node-webkit issue. https://github.com/rogerwang/node-webkit/wiki/The-solution-of-lacking-libudev.so.0 I'll see if i can get a workaround in place.
I experimented with symbolically linking libudev.so.1 in (1) the same directory as the Komanda binary, (2) the top directory, (3) the directory in the cache folder with nw in it, but none of those worked. So it may require a workaround elsewhere.
Note: I successfully found a symlink location to get it to work. Komanda now runs successfully. To do so I did ln -s /usr/lib64/libudev.so.1 /usr/lib64/libudev.so.0.
Ideally, during the build process a symlink should be done, but I feel that the grunt node-webkit builder may get in the way of that working correctly.
@eugene-bulkin awesome man - i'll get this added to the wiki under FAQ - I wonder if there is a way for Komanda to check and do this automatically?
It's possible but I don't think it can be done with any sort of reliability. You would essentially have to run a command to find libudev.so.0 and if it's not found, automatically do some linking. But I had to use sudo to run that link, so there would have to be some sort of place to put the .so file that would allow it to be local and still run correctly.
Perhaps running with a PATH set or something.
@eugene-bulkin we will just have to wait for a new version of node-webkit or I can pull the source and build a new linux binary with the path changes for newer systems.
@eugene-bulkin @mephux , the best and most effective way is just to do a symlink this problem has been known for some time and mostlikly not be fixed unless its done manually.
It's not advisable to ask the user to ever add a symlink in their /lib64 or /usr/lib64 directories to a soname of a different ABI (in this case a libudev.so.0 symlink to libudev.so.1). Here's an ok explanation of why: http://askubuntu.com/questions/369310/how-to-fix-missing-libudev-so-0-for-chrome-to-start-again/531098#531098
There's plenty more on stackoverflow and others why this is a bad idea, but the summary is: applications expecting libudev.so.0 will try to link to that, seeing the sharedlib in the respective directory. However, since it's a symlink, they'll actually get libudev.so.1, which may implement a completely different, possibly incompatible ABI. After that, the user may get linker errors with binaries linked to libudev.so.1, but expecting libudev.so.0 which will cause trouble in the future.
There's some decent advice here: https://github.com/nwjs/nw.js/wiki/The-solution-of-lacking-libudev.so.0, pretty much all of which will work. The shell script will work the best, because it adds a symlink to libudev.so.1 for nw running Komanda only. In the first item on that link they actually have already done a lot of the heavy lifting for you in terms of finding what the directories are on each flavor of linux. Just my $0.02, as I ran into this problem, implemented the symlink solution, but didn't realize my folly until much later!
