Sabayon/Gentoo: libudev.so.0: cannot open shared object file: No such file or directory #161

Closed
jotbe opened this Issue Nov 6, 2012 · 58 comments

Comments

Projects
None yet
@jotbe

jotbe commented Nov 6, 2012

After downloading the 64bit Version of Light Table (see #158) it still did not start:

$ ./LightTable 
./LightTable: error while loading shared libraries: libudev.so.0: cannot open shared object file: No such file or directory

I was able to workaround this issue by creating a symlink:

$ sudo ln -s /usr/lib/libudev.so.1.1.0 /usr/lib/libudev.so.0

Maybe recompiling Light Table using the latest systemd libs might help. Not sure though.

@iperdomo

This comment has been minimized.

Show comment Hide comment
@iperdomo

iperdomo Nov 6, 2012

Same happens when trying with Arch Linux

$ uname -m -r
3.6.5-1-ARCH x86_64

$ ./LightTable
./LightTable: error while loading shared libraries: libudev.so.0: cannot open shared object file: No such file or directory

See comments on issue #166

iperdomo commented Nov 6, 2012

Same happens when trying with Arch Linux

$ uname -m -r
3.6.5-1-ARCH x86_64

$ ./LightTable
./LightTable: error while loading shared libraries: libudev.so.0: cannot open shared object file: No such file or directory

See comments on issue #166

@rickeyvisinski-kanban

This comment has been minimized.

Show comment Hide comment
@rickeyvisinski-kanban

rickeyvisinski-kanban Nov 6, 2012

Please don't symlink different versions of libs against each other. You can end up with very surprising results. We either need to wait for a recompilation for all the non-debian systems, or preferably a static linked binary, which is asked for in the issue you linked.

Please don't symlink different versions of libs against each other. You can end up with very surprising results. We either need to wait for a recompilation for all the non-debian systems, or preferably a static linked binary, which is asked for in the issue you linked.

@jotbe

This comment has been minimized.

Show comment Hide comment
@jotbe

jotbe Nov 8, 2012

@ibdknox: Unfortunately, this doesn't fix the mentioned problem. I just deleted the symlink of my workaround and got the same error message.

jotbe commented Nov 8, 2012

@ibdknox: Unfortunately, this doesn't fix the mentioned problem. I just deleted the symlink of my workaround and got the same error message.

@iperdomo

This comment has been minimized.

Show comment Hide comment
@iperdomo

iperdomo Nov 8, 2012

@ibdknox
See the comments on issue #166, why not produce a static build ?

iperdomo commented Nov 8, 2012

@ibdknox
See the comments on issue #166, why not produce a static build ?

@ibdknox

This comment has been minimized.

Show comment Hide comment
@ibdknox

ibdknox Nov 8, 2012

Owner

I'll see how far I can get with that, but my understanding is that it's non-trivial to build a static version of chromium

Owner

ibdknox commented Nov 8, 2012

I'll see how far I can get with that, but my understanding is that it's non-trivial to build a static version of chromium

@iperdomo

This comment has been minimized.

Show comment Hide comment
@iperdomo

iperdomo Nov 8, 2012

Just for the record, the latest build still don't work in Arch Linux (retrieved on 2012-11-08 08:26 UTC)

iperdomo commented Nov 8, 2012

Just for the record, the latest build still don't work in Arch Linux (retrieved on 2012-11-08 08:26 UTC)

@jotbe

This comment has been minimized.

Show comment Hide comment
@jotbe

jotbe Nov 8, 2012

If it is about chromium, here is a corresponding bug report: http://code.google.com/p/chromium/issues/detail?id=130019

jotbe commented Nov 8, 2012

If it is about chromium, here is a corresponding bug report: http://code.google.com/p/chromium/issues/detail?id=130019

@redalastor

This comment has been minimized.

Show comment Hide comment
@redalastor

redalastor Nov 11, 2012

Would it be possible to have the old clojure server / browser mode for those of us who can't run the compiled version?

Would it be possible to have the old clojure server / browser mode for those of us who can't run the compiled version?

@Gonzih

This comment has been minimized.

Show comment Hide comment
@Gonzih

Gonzih Dec 26, 2012

Just downloaded latest build.

uname -m -r
3.6.10-1-ARCH x86_64

LightTable: error while loading shared libraries: libudev.so.0: cannot open shared object file: No such file or directory

Same issue. Any help on that issue?

Thanks!

Gonzih commented Dec 26, 2012

Just downloaded latest build.

uname -m -r
3.6.10-1-ARCH x86_64

LightTable: error while loading shared libraries: libudev.so.0: cannot open shared object file: No such file or directory

Same issue. Any help on that issue?

Thanks!

@ibdknox

This comment has been minimized.

Show comment Hide comment
@ibdknox

ibdknox Dec 26, 2012

Owner

Right now the symlink that the OP mentioned is the best workaround. This is actually a bug in Chromium so we're kind of stuck until it gets fixed there.

Owner

ibdknox commented Dec 26, 2012

Right now the symlink that the OP mentioned is the best workaround. This is actually a bug in Chromium so we're kind of stuck until it gets fixed there.

@rogerwang

This comment has been minimized.

Show comment Hide comment
@rogerwang

rogerwang Dec 26, 2012

This is actually an issue in the Linux distribution (Arch, etc) and should be fixed there: the distribution should ship libudev.so.0 and libudev.so.1 in the same way they ship gtk2 and gtk3 simultaneously.

Regarding Linux dynamic libraries, the first digit after the filename after '.so' marks the API version, and the following numbers marks the library version (major and minor). libudev.so.0 means it's a up-to-date version providing API 0 of libudev. The API version number increase means it isn't compatible with the previous version of API any more. So it's a common practice for distributions to ship both because they can't expect all the applications based on previous API to migrate to the new API suddenly, after the library breaks the API backward compatibility.

This is actually an issue in the Linux distribution (Arch, etc) and should be fixed there: the distribution should ship libudev.so.0 and libudev.so.1 in the same way they ship gtk2 and gtk3 simultaneously.

Regarding Linux dynamic libraries, the first digit after the filename after '.so' marks the API version, and the following numbers marks the library version (major and minor). libudev.so.0 means it's a up-to-date version providing API 0 of libudev. The API version number increase means it isn't compatible with the previous version of API any more. So it's a common practice for distributions to ship both because they can't expect all the applications based on previous API to migrate to the new API suddenly, after the library breaks the API backward compatibility.

@rickeyvisinski-kanban

This comment has been minimized.

Show comment Hide comment
@rickeyvisinski-kanban

rickeyvisinski-kanban Jan 17, 2013

I don't know if anyone else has found a workaround to this, but I shamelessly borrowed from the google-chrome launcher script and it now launches on any system with libudev.so.1. Here is is https://gist.github.com/4559886

I don't know if anyone else has found a workaround to this, but I shamelessly borrowed from the google-chrome launcher script and it now launches on any system with libudev.so.1. Here is is https://gist.github.com/4559886

@dkhenry

This comment has been minimized.

Show comment Hide comment
@dkhenry

dkhenry Jan 26, 2013

On fedora 18 it took this line to get it working

sudo ln -s /usr/lib64/libudev.so.1.2.1 /usr/lib64/libudev.so.0

dkhenry commented Jan 26, 2013

On fedora 18 it took this line to get it working

sudo ln -s /usr/lib64/libudev.so.1.2.1 /usr/lib64/libudev.so.0
@zoowar

This comment has been minimized.

Show comment Hide comment
@zoowar

zoowar Jan 27, 2013

Rather than muck with your system, consider the following work-around.

cd LightTable
ln -s /usr/lib64/libudev.so.1.2.1 libudev.so.0
LD_LIBRARY_PATH=:/. ./LightTable

zoowar commented Jan 27, 2013

Rather than muck with your system, consider the following work-around.

cd LightTable
ln -s /usr/lib64/libudev.so.1.2.1 libudev.so.0
LD_LIBRARY_PATH=:/. ./LightTable
@bendlas

This comment has been minimized.

Show comment Hide comment
@bendlas

bendlas Feb 28, 2013

google-chrome ships with libudev.so.0.13.1, probably because of that bug.
I installed and symlinked /opt/google/chrome/libudev.so.0.13.1 to /usr/local/lib64
That fixed it on my gentoo box

bendlas commented Feb 28, 2013

google-chrome ships with libudev.so.0.13.1, probably because of that bug.
I installed and symlinked /opt/google/chrome/libudev.so.0.13.1 to /usr/local/lib64
That fixed it on my gentoo box

@kentfredric

This comment has been minimized.

Show comment Hide comment
@kentfredric

kentfredric Feb 28, 2013

This is actually an issue in the Linux distribution (Arch, etc) and should be fixed there: the distribution should ship > libudev.so.0 and libudev.so.1 in the same way they ship gtk2 and gtk3 simultaneously.

That seems insane to me as a "right" solution, thats akin to saying the right solution to a problem is to make everyone install 2 copies of firefox. Yes, an exaggeration. But its not quite the same kettle of fish.

I would not request any flavour of linux to ship 2 different versions of udev simultaneously, thats crazy.

This is actually an issue in the Linux distribution (Arch, etc) and should be fixed there: the distribution should ship > libudev.so.0 and libudev.so.1 in the same way they ship gtk2 and gtk3 simultaneously.

That seems insane to me as a "right" solution, thats akin to saying the right solution to a problem is to make everyone install 2 copies of firefox. Yes, an exaggeration. But its not quite the same kettle of fish.

I would not request any flavour of linux to ship 2 different versions of udev simultaneously, thats crazy.

@kentfredric

This comment has been minimized.

Show comment Hide comment
@kentfredric

kentfredric Feb 28, 2013

And I'm not so sure the problem is purely chrome(,ium) related. I have chromium 25.0.1364.97 working just fine. That said, its not a prebuilt chromium, but one I built from source from Gentoo Portage.

It seems the problem is more related to static built binaries than anything else.

( Though that said, chrome having code that needs udev to work seems incredibly crazy in itself.

@rickeyvisinski-kanban is on to the right stuff I think.

It may be advantageous to ship a dynamically linked binary, with as many direct dependencies you need shipped also pre-built dynamically in the lib/ dir, with a script like the one @rickeyvisinski-kanban gave to launch it.

That way, if one of those libraries is wonky and depends on non-existing system libraries ( like udev.so.0 ) but the user already has a working compatible version of those libraries already in their system, they can delete the shipped version and their system version will take its place.

In essence: Bundle libraries, and downstream ( linux vendors ) will delete ones that are already existing in the system and are compatible replacements.

Thats really as flexible as you'll get without having to release the source code itself.

And I'm not so sure the problem is purely chrome(,ium) related. I have chromium 25.0.1364.97 working just fine. That said, its not a prebuilt chromium, but one I built from source from Gentoo Portage.

It seems the problem is more related to static built binaries than anything else.

( Though that said, chrome having code that needs udev to work seems incredibly crazy in itself.

@rickeyvisinski-kanban is on to the right stuff I think.

It may be advantageous to ship a dynamically linked binary, with as many direct dependencies you need shipped also pre-built dynamically in the lib/ dir, with a script like the one @rickeyvisinski-kanban gave to launch it.

That way, if one of those libraries is wonky and depends on non-existing system libraries ( like udev.so.0 ) but the user already has a working compatible version of those libraries already in their system, they can delete the shipped version and their system version will take its place.

In essence: Bundle libraries, and downstream ( linux vendors ) will delete ones that are already existing in the system and are compatible replacements.

Thats really as flexible as you'll get without having to release the source code itself.

@bendlas

This comment has been minimized.

Show comment Hide comment
@bendlas

bendlas Feb 28, 2013

FWIW my vote is for shipping with at least libudev.so.0, like apparently every binary distibutor does (observed with google-chrome and steam)

To the people ln-s ing libudev.so.1: don't do it. And if you do, don't post it here as a "solution". It just leads to even worse breakage: The kind you don't get clear error messages about.

bendlas commented Feb 28, 2013

FWIW my vote is for shipping with at least libudev.so.0, like apparently every binary distibutor does (observed with google-chrome and steam)

To the people ln-s ing libudev.so.1: don't do it. And if you do, don't post it here as a "solution". It just leads to even worse breakage: The kind you don't get clear error messages about.

@rickeyvisinski-kanban

This comment has been minimized.

Show comment Hide comment
@rickeyvisinski-kanban

rickeyvisinski-kanban Feb 28, 2013

As I said in my post above, that is the exact launcher script that comes with Google Chrome modified for Light Table.

Google Chrome doesn't doesn't ship with libudev.so.0, it provides a symlink named libudev.so.0 that points to the existing system libudev. And in Light Tables case, if it is good enough for Google, why shouldn't it be safe enough for their distribution of Chromium?

As I said in my post above, that is the exact launcher script that comes with Google Chrome modified for Light Table.

Google Chrome doesn't doesn't ship with libudev.so.0, it provides a symlink named libudev.so.0 that points to the existing system libudev. And in Light Tables case, if it is good enough for Google, why shouldn't it be safe enough for their distribution of Chromium?

@bendlas

This comment has been minimized.

Show comment Hide comment
@bendlas

bendlas Feb 28, 2013

Are you positive about that? Neither your gist nor my installation look like they could support that claim:

% ls -al /opt/google/chrome 
# ... snip ...
lrwxrwxrwx 1 root root       17 Feb 25 18:00 libudev.so.0 -> libudev.so.0.13.1
-rwxr-xr-x 1 root root    55792 Jan 20 07:24 libudev.so.0.13.1

FYI LD_LIBRARY_PATH="$HERE:$HERE/lib:$LD_LIBRARY_PATH" sets the search path for the dynamic linker, which would find the symlink, which would point to the 0.13.1 version shipped with chrome.

Also there is a reason, that libudev.so.0 is not symlinked to libudev.so.1 in any distro, ever.

bendlas commented Feb 28, 2013

Are you positive about that? Neither your gist nor my installation look like they could support that claim:

% ls -al /opt/google/chrome 
# ... snip ...
lrwxrwxrwx 1 root root       17 Feb 25 18:00 libudev.so.0 -> libudev.so.0.13.1
-rwxr-xr-x 1 root root    55792 Jan 20 07:24 libudev.so.0.13.1

FYI LD_LIBRARY_PATH="$HERE:$HERE/lib:$LD_LIBRARY_PATH" sets the search path for the dynamic linker, which would find the symlink, which would point to the 0.13.1 version shipped with chrome.

Also there is a reason, that libudev.so.0 is not symlinked to libudev.so.1 in any distro, ever.

@kentfredric

This comment has been minimized.

Show comment Hide comment
@kentfredric

kentfredric Feb 28, 2013

Oh, and there's yet another approach you can try:

xxd LightTable LightTable.xxd
patch LightTable.xxd < libudev.patch
xxd -r LightTable.xxd LightTable.new
chmod  u+x LightTable.new

And libudev.patch is:

--- LightTable.xxd.old  2013-03-01 11:19:39.166413342 +1300
+++ LightTable.xxd.new  2013-03-01 11:20:24.987340512 +1300
@@ -131828,7 +131828,7 @@
 0202f30: 7573 2d31 2e73 6f2e 3300 6c69 6258 6578  us-1.so.3.libXex
 0202f40: 742e 736f 2e36 006c 6962 5866 6978 6573  t.so.6.libXfixes
 0202f50: 2e73 6f2e 3300 6c69 6275 6465 762e 736f  .so.3.libudev.so
-0202f60: 2e30 006c 6962 6578 7061 742e 736f 2e31  .0.libexpat.so.1
+0202f60: 2e31 006c 6962 6578 7061 742e 736f 2e31  .1.libexpat.so.1
 0202f70: 0000 0000 0000 0000 1b40 0000 e05d 0000  .........@...]..
 0202f80: 2f13 0000 6d11 0000 2b10 0000 695d 0000  /...m...+...i]..
 0202f90: 0000 0000 105c 0000 3339 0000 9b3b 0000  .....\..39...;..

I'm kinda surprised it worked really.

Oh, and there's yet another approach you can try:

xxd LightTable LightTable.xxd
patch LightTable.xxd < libudev.patch
xxd -r LightTable.xxd LightTable.new
chmod  u+x LightTable.new

And libudev.patch is:

--- LightTable.xxd.old  2013-03-01 11:19:39.166413342 +1300
+++ LightTable.xxd.new  2013-03-01 11:20:24.987340512 +1300
@@ -131828,7 +131828,7 @@
 0202f30: 7573 2d31 2e73 6f2e 3300 6c69 6258 6578  us-1.so.3.libXex
 0202f40: 742e 736f 2e36 006c 6962 5866 6978 6573  t.so.6.libXfixes
 0202f50: 2e73 6f2e 3300 6c69 6275 6465 762e 736f  .so.3.libudev.so
-0202f60: 2e30 006c 6962 6578 7061 742e 736f 2e31  .0.libexpat.so.1
+0202f60: 2e31 006c 6962 6578 7061 742e 736f 2e31  .1.libexpat.so.1
 0202f70: 0000 0000 0000 0000 1b40 0000 e05d 0000  .........@...]..
 0202f80: 2f13 0000 6d11 0000 2b10 0000 695d 0000  /...m...+...i]..
 0202f90: 0000 0000 105c 0000 3339 0000 9b3b 0000  .....\..39...;..

I'm kinda surprised it worked really.

@bendlas

This comment has been minimized.

Show comment Hide comment
@bendlas

bendlas Feb 28, 2013

facepalm it's the same as symlinking .1 to .0 only worse, because now you have two problems:

  1. A locally modified binary
  2. an incompatible library linked into that

Guys, seriously. It might just be that it doesn't cause trouble, but if it eventually does, nobody will know what hit them. Spreading that kind of advice borders on malice.
I always considered the clojure community to be more careful than this.

bendlas commented Feb 28, 2013

facepalm it's the same as symlinking .1 to .0 only worse, because now you have two problems:

  1. A locally modified binary
  2. an incompatible library linked into that

Guys, seriously. It might just be that it doesn't cause trouble, but if it eventually does, nobody will know what hit them. Spreading that kind of advice borders on malice.
I always considered the clojure community to be more careful than this.

@kentfredric

This comment has been minimized.

Show comment Hide comment
@kentfredric

kentfredric Feb 28, 2013

Well, yes, this is going to achieve the same effect as the symlink, ( which I concede is the wrong approach, even if it does "work", however temporarily ) but it makes it local to that binary only ( ie: can't leak into other programs ).

I really would like to see how the more realistic approach: shipping a whole bunch of libraries as dependencies instead of a pure static link, pans out.

At least with that approach,

main program -> shipped dependency -> system library

makes a more flexible build than

main program + static dependencies linked in -> system library

because with the former, its easier to drop in alternative values of shipped dependency with working links to system libraries, ie: What google and everyone sane actually does with shipping binary builds.

You could even make the download smaller by breaking the shipped stuff into 2 parts, "base" and "support", and people could use the dynalinked binary and if it "just works" they'll never need those support libraries at all.

And this proves to be a good thing, esp with regard to memory consumption: Because the point of a shared library is its not only shared on disk, but shared in memory, and why waste system memory by loading multiple copies of the same thing ( what you'll get with static or shipped pre-built libraries ) when you don't need to.

Well, yes, this is going to achieve the same effect as the symlink, ( which I concede is the wrong approach, even if it does "work", however temporarily ) but it makes it local to that binary only ( ie: can't leak into other programs ).

I really would like to see how the more realistic approach: shipping a whole bunch of libraries as dependencies instead of a pure static link, pans out.

At least with that approach,

main program -> shipped dependency -> system library

makes a more flexible build than

main program + static dependencies linked in -> system library

because with the former, its easier to drop in alternative values of shipped dependency with working links to system libraries, ie: What google and everyone sane actually does with shipping binary builds.

You could even make the download smaller by breaking the shipped stuff into 2 parts, "base" and "support", and people could use the dynalinked binary and if it "just works" they'll never need those support libraries at all.

And this proves to be a good thing, esp with regard to memory consumption: Because the point of a shared library is its not only shared on disk, but shared in memory, and why waste system memory by loading multiple copies of the same thing ( what you'll get with static or shipped pre-built libraries ) when you don't need to.

@rickeyvisinski-kanban

This comment has been minimized.

Show comment Hide comment
@rickeyvisinski-kanban

rickeyvisinski-kanban Feb 28, 2013

fyi @bendlas . I know you shouldn't symlink shared libs since I don't know what features are expected even if the api is the same; however, maybe the Chrome/Chromium developer who wrote it do.

% ls -la /opt/google/chrome
-rwxr-xr-x 1 root root 89681320 Feb 26 05:57 chrome
-rwxr-xr-x 1 root root 1666 Feb 26 05:57 google-chrome
-rw-r--r-- 1 root root 2592680 Feb 26 05:57 libffmpegsumo.so
-rw-r--r-- 1 root root 6656392 Feb 26 05:57 libpdf.so
-rw-r--r-- 1 root root 459192 Feb 26 05:57 libppGoogleNaClPluginChrome.so
lrwxrwxrwx 1 root root 21 Feb 27 12:24 libudev.so.0 -> /usr/lib/libudev.so.1
-rw-r--r-- 1 root root 64216 Feb 26 05:57 libwidevinecdmadapter.so
-rw-r--r-- 1 root root 6777842 Feb 26 05:57 libwidevinecdm.so

fyi @bendlas . I know you shouldn't symlink shared libs since I don't know what features are expected even if the api is the same; however, maybe the Chrome/Chromium developer who wrote it do.

% ls -la /opt/google/chrome
-rwxr-xr-x 1 root root 89681320 Feb 26 05:57 chrome
-rwxr-xr-x 1 root root 1666 Feb 26 05:57 google-chrome
-rw-r--r-- 1 root root 2592680 Feb 26 05:57 libffmpegsumo.so
-rw-r--r-- 1 root root 6656392 Feb 26 05:57 libpdf.so
-rw-r--r-- 1 root root 459192 Feb 26 05:57 libppGoogleNaClPluginChrome.so
lrwxrwxrwx 1 root root 21 Feb 27 12:24 libudev.so.0 -> /usr/lib/libudev.so.1
-rw-r--r-- 1 root root 64216 Feb 26 05:57 libwidevinecdmadapter.so
-rw-r--r-- 1 root root 6777842 Feb 26 05:57 libwidevinecdm.so

@rickeyvisinski-kanban

This comment has been minimized.

Show comment Hide comment
@rickeyvisinski-kanban

rickeyvisinski-kanban Feb 28, 2013

@kentfredric +1 for binary patching, well done. There is always another solution.

@kentfredric +1 for binary patching, well done. There is always another solution.

@kentfredric

This comment has been minimized.

Show comment Hide comment
@kentfredric

kentfredric Feb 28, 2013

It seems Gentoo may do something slightly more sane than factory installs of Chrome.

Reading the source of the chrome ebuild I found this:

mirror://gentoo/google-chrome-libudev-0.13.1-amd64.tar.xz
mirror://gentoo/google-chrome-libudev-0.13.1-x86.tar.xz

Those might prove to be some binary packages worthy of stealing and shipping ;)

It seems Gentoo may do something slightly more sane than factory installs of Chrome.

Reading the source of the chrome ebuild I found this:

mirror://gentoo/google-chrome-libudev-0.13.1-amd64.tar.xz
mirror://gentoo/google-chrome-libudev-0.13.1-x86.tar.xz

Those might prove to be some binary packages worthy of stealing and shipping ;)

@bendlas

This comment has been minimized.

Show comment Hide comment
@bendlas

bendlas Feb 28, 2013

OK, I thought it was due to you looking at chromium and me looking at google-chrome, but now I have to say:
I don't know which version of google-chrome you are on (SCNR ;-), but fyi, mine is the current stable in gentoo 25.0.1364.97
Right now I'm building chromium aswell, to double check.
Anyway, I'll refrain from exploring that particular facet of the issue any further. The warning should be hard to ignore for anyone stumbling upon this thread.

And sorry if anyone got offended by my dramatic tone. I appreciate you all taking time to find solutions.

#EDIT @kentfredric yeah, I was just starting to suspect that .... I've seen some stuff from google ...

bendlas commented Feb 28, 2013

OK, I thought it was due to you looking at chromium and me looking at google-chrome, but now I have to say:
I don't know which version of google-chrome you are on (SCNR ;-), but fyi, mine is the current stable in gentoo 25.0.1364.97
Right now I'm building chromium aswell, to double check.
Anyway, I'll refrain from exploring that particular facet of the issue any further. The warning should be hard to ignore for anyone stumbling upon this thread.

And sorry if anyone got offended by my dramatic tone. I appreciate you all taking time to find solutions.

#EDIT @kentfredric yeah, I was just starting to suspect that .... I've seen some stuff from google ...

@kentfredric

This comment has been minimized.

Show comment Hide comment
@kentfredric

kentfredric Feb 28, 2013

https://gist.github.com/kentfredric/5061054

A variation of the previous script that automatically provisions a libudev.so.0 from gentoo's prebuilt version of it.

Automatically creates a lib/ the first time its run.

cd $LIGHTTABLEDIR
wget https://gist.github.com/kentfredric/5061054/raw/592035bcc4551f6fb254668cf24d9bf9433a4a36/lighttable
chmod u+x lighttable
./lighttable

https://gist.github.com/kentfredric/5061054

A variation of the previous script that automatically provisions a libudev.so.0 from gentoo's prebuilt version of it.

Automatically creates a lib/ the first time its run.

cd $LIGHTTABLEDIR
wget https://gist.github.com/kentfredric/5061054/raw/592035bcc4551f6fb254668cf24d9bf9433a4a36/lighttable
chmod u+x lighttable
./lighttable
@bendlas

This comment has been minimized.

Show comment Hide comment
@bendlas

bendlas Feb 28, 2013

@kentfredric Well played, sir!

Seeing as this can be considered a proper fix, can we get this into the next LightTable release, please?
(not nessecarily the wget part ;-)

#EDIT Also, apparently, ld can be passed a -rpath option, so that setting LD_LIBRARY_PATH is not needed

bendlas commented Feb 28, 2013

@kentfredric Well played, sir!

Seeing as this can be considered a proper fix, can we get this into the next LightTable release, please?
(not nessecarily the wget part ;-)

#EDIT Also, apparently, ld can be passed a -rpath option, so that setting LD_LIBRARY_PATH is not needed

@rickeyvisinski-kanban

This comment has been minimized.

Show comment Hide comment
@rickeyvisinski-kanban

rickeyvisinski-kanban Mar 1, 2013

The way this thread has gone, the non-{debian,fedora} people are going to have the wget fix as our default install. There are worse options... No offense taken.

cc: @ibdknox https://gist.github.com/kentfredric/5061054

The way this thread has gone, the non-{debian,fedora} people are going to have the wget fix as our default install. There are worse options... No offense taken.

cc: @ibdknox https://gist.github.com/kentfredric/5061054

@kentfredric

This comment has been minimized.

Show comment Hide comment
@kentfredric

kentfredric Mar 1, 2013

@rickeyvisinski-kanban I wasn't suggesting using wget in the shipped install of LightTable, it was more a script tailored to maximise its power as a 3rd party utility.

LightTable should fetch all the dependencies and pack them into the release, eliminating the need for all that wget nonsense.

@rickeyvisinski-kanban I wasn't suggesting using wget in the shipped install of LightTable, it was more a script tailored to maximise its power as a 3rd party utility.

LightTable should fetch all the dependencies and pack them into the release, eliminating the need for all that wget nonsense.

@rickeyvisinski-kanban

This comment has been minimized.

Show comment Hide comment
@rickeyvisinski-kanban

rickeyvisinski-kanban Mar 1, 2013

I agree completely, its why I first proposed using the google-chrome launcher script. I probably should have made it a separate ticket rather than piling on this one though.

As for wget, I was attempting to make a joke about all non fedora or debian flavored distro's would still have to download the gentoo library.

cheers

I agree completely, its why I first proposed using the google-chrome launcher script. I probably should have made it a separate ticket rather than piling on this one though.

As for wget, I was attempting to make a joke about all non fedora or debian flavored distro's would still have to download the gentoo library.

cheers

@no-op

This comment has been minimized.

Show comment Hide comment
@no-op

no-op Mar 7, 2013

benlas' comment about Google chrome having libudev.so.0 solved the issue for me. For reference, I'm running Fedora 18 on a 64bit machine with Google chrome installed and just needed the one link to get LightTable to launch:

sudo ln -s  /opt/google/chrome/libudev.so.0 /usr/lib64/

no-op commented Mar 7, 2013

benlas' comment about Google chrome having libudev.so.0 solved the issue for me. For reference, I'm running Fedora 18 on a 64bit machine with Google chrome installed and just needed the one link to get LightTable to launch:

sudo ln -s  /opt/google/chrome/libudev.so.0 /usr/lib64/
@abeburnett

This comment has been minimized.

Show comment Hide comment
@abeburnett

abeburnett Apr 30, 2013

This is apparently still an issue on Chrome 28 running on Ubuntu 13.04.

This is apparently still an issue on Chrome 28 running on Ubuntu 13.04.

@alkavan

This comment has been minimized.

Show comment Hide comment
@alkavan

alkavan May 1, 2013

https://gist.github.com/rickeyvisinski-kanban/4559886/raw/77c5af46b64edda626784db96628a1c5440c5555/lighttable

/usr/lib/libudev.a
/usr/lib/libudev.so
/usr/lib/libudev.so.1
/usr/lib/libudev.so.1.3.2

worked on 3.8.8-2-ARCH x86_64

alkavan commented May 1, 2013

https://gist.github.com/rickeyvisinski-kanban/4559886/raw/77c5af46b64edda626784db96628a1c5440c5555/lighttable

/usr/lib/libudev.a
/usr/lib/libudev.so
/usr/lib/libudev.so.1
/usr/lib/libudev.so.1.3.2

worked on 3.8.8-2-ARCH x86_64

@samebchase

This comment has been minimized.

Show comment Hide comment
@samebchase

samebchase May 6, 2013

On 3.8.11-1-ARCH x86_64,

Doing this:
sudo ln -s /usr/lib64/libudev.so.1.3.3 libudev.so.0
before running @alkavan's gist worked.

On 3.8.11-1-ARCH x86_64,

Doing this:
sudo ln -s /usr/lib64/libudev.so.1.3.3 libudev.so.0
before running @alkavan's gist worked.

@kentfredric

This comment has been minimized.

Show comment Hide comment
@kentfredric

kentfredric May 6, 2013

People, please, read the discussion, and DONT symlink libudev.so.1.? to libudev.so.0, its just asking for bad things to happen. It may "work", but may also silently destroy important parts of your system, because those numbers after the .so., they're the API version, and different API versions have different behaviour.

So, where possible, download and use a prebuild version of libudev.so.0 instead.

Symlinks should be your last option, not your first.

People, please, read the discussion, and DONT symlink libudev.so.1.? to libudev.so.0, its just asking for bad things to happen. It may "work", but may also silently destroy important parts of your system, because those numbers after the .so., they're the API version, and different API versions have different behaviour.

So, where possible, download and use a prebuild version of libudev.so.0 instead.

Symlinks should be your last option, not your first.

@nullbio

This comment has been minimized.

Show comment Hide comment
@nullbio

nullbio May 16, 2013

I just downloaded the latest version (0.4.10) and was getting the libudev error. After symlinking I'm getting: error while loading shared libraries: libudev.so.0: wrong ELF class: ELFCLASS32

Tried the 64bit version, results in the original libudev error.

nullbio commented May 16, 2013

I just downloaded the latest version (0.4.10) and was getting the libudev error. After symlinking I'm getting: error while loading shared libraries: libudev.so.0: wrong ELF class: ELFCLASS32

Tried the 64bit version, results in the original libudev error.

@kentfredric

This comment has been minimized.

Show comment Hide comment
@kentfredric

kentfredric May 17, 2013

Hrm, I was going to suggest trying using Gentoo's prebuilt ones, but I just discovered they're not doing that any more for Chrome because it causes its own type of problem, and as such, prebuilds are no longer on their mirrors.

https://bugs.gentoo.org/show_bug.cgi?id=458320

^ Suggests a prebuilt libudev.so.0 still tries to call libudev.so.1, which causes its own barrage of problems.

I guess its just a matter of time until LightTable instead just does the reasonable thing and ships builds that build against a recent libudev, then it only becomes a problem for people with old systems.

Hrm, I was going to suggest trying using Gentoo's prebuilt ones, but I just discovered they're not doing that any more for Chrome because it causes its own type of problem, and as such, prebuilds are no longer on their mirrors.

https://bugs.gentoo.org/show_bug.cgi?id=458320

^ Suggests a prebuilt libudev.so.0 still tries to call libudev.so.1, which causes its own barrage of problems.

I guess its just a matter of time until LightTable instead just does the reasonable thing and ships builds that build against a recent libudev, then it only becomes a problem for people with old systems.

@ibdknox

This comment has been minimized.

Show comment Hide comment
@ibdknox

ibdknox May 17, 2013

Owner

Light Table you mean? ;)

It's actually node-webkit that needs to build against a newer libudev. Once they do, all will be well.

Owner

ibdknox commented May 17, 2013

Light Table you mean? ;)

It's actually node-webkit that needs to build against a newer libudev. Once they do, all will be well.

@kentfredric

This comment has been minimized.

Show comment Hide comment
@kentfredric

kentfredric May 17, 2013

Er, yeah. Corrected my post.

Though, you probably could build node-webkit yourself vs newer libudev, and then build LightTable vs that.

Er, yeah. Corrected my post.

Though, you probably could build node-webkit yourself vs newer libudev, and then build LightTable vs that.

@ibdknox

This comment has been minimized.

Show comment Hide comment
@ibdknox

ibdknox May 17, 2013

Owner

I believe changes would have to be made to the fork of chromium to do that. If it's as trivial as building it against a newer libudev, I'd happily do that.

Owner

ibdknox commented May 17, 2013

I believe changes would have to be made to the fork of chromium to do that. If it's as trivial as building it against a newer libudev, I'd happily do that.

@nullbio

This comment has been minimized.

Show comment Hide comment
@nullbio

nullbio May 17, 2013

Fingers crossed you can get it resolved soon, I was looking forward to
trying LightTable!

On Fri, May 17, 2013 at 11:45 AM, Chris Granger notifications@github.comwrote:

I believe changes would have to be made to the fork of chromium to do
that. If it's as trivial as building it against a newer libudev, I'd
happily do that.


Reply to this email directly or view it on GitHubhttps://github.com/Kodowa/Light-Table-Playground/issues/161#issuecomment-18039648
.

nullbio commented May 17, 2013

Fingers crossed you can get it resolved soon, I was looking forward to
trying LightTable!

On Fri, May 17, 2013 at 11:45 AM, Chris Granger notifications@github.comwrote:

I believe changes would have to be made to the fork of chromium to do
that. If it's as trivial as building it against a newer libudev, I'd
happily do that.


Reply to this email directly or view it on GitHubhttps://github.com/Kodowa/Light-Table-Playground/issues/161#issuecomment-18039648
.

@kentfredric

This comment has been minimized.

Show comment Hide comment
@kentfredric

kentfredric May 17, 2013

For the sake of anyone else following this bug, this bug is really this bug upstream: rogerwang/node-webkit#136

But upstream have already closed the issue there, which is silly, because then it ceases to be obvious when its no longer a problem in their built versions.

And this problem is now occurring on more mainstream distributions too. As recently as 9 days ago :/

I might try building it myself from source locally and see how I go with it, it might just work "as is", though comments on upstreams bug suggests it needs code changes for the new API.

For the sake of anyone else following this bug, this bug is really this bug upstream: rogerwang/node-webkit#136

But upstream have already closed the issue there, which is silly, because then it ceases to be obvious when its no longer a problem in their built versions.

And this problem is now occurring on more mainstream distributions too. As recently as 9 days ago :/

I might try building it myself from source locally and see how I go with it, it might just work "as is", though comments on upstreams bug suggests it needs code changes for the new API.

@ibdknox

This comment has been minimized.

Show comment Hide comment
@rogerwang

This comment has been minimized.

Show comment Hide comment
@rogerwang

rogerwang May 17, 2013

Last time when I checked, Google is doing symbol linking from libudev.so.1 to libudev.so.0 in their official Chrome Linux package.

And this is a rather package issue, an app need to create separate packages for system with libudev.so.0 and libudev.so.1 respectively even if their code support both version of APIs.

Last time when I checked, Google is doing symbol linking from libudev.so.1 to libudev.so.0 in their official Chrome Linux package.

And this is a rather package issue, an app need to create separate packages for system with libudev.so.0 and libudev.so.1 respectively even if their code support both version of APIs.

@ibdknox

This comment has been minimized.

Show comment Hide comment
@ibdknox

ibdknox May 17, 2013

Owner

So I just cracked open the .deb for chrome and this is what they do:

# Fedora 18 now has libudev.so.1. http://crbug.com/145160
# Same for Ubuntu 13.04. http://crbug.com/226002
LIBUDEV_0=libudev.so.0
LIBUDEV_1=libudev.so.1

add_udev_symlinks() {
  get_lib_dir
  if [ -f "/$LIBDIR/$LIBUDEV_0" -o -f "/usr/$LIBDIR/$LIBUDEV_0" -o -f "/lib/$LIBUDEV_0" ]; then
    return 0
  fi

  if [ -f "/$LIBDIR/$LIBUDEV_1" ]; then
    ln -snf "/$LIBDIR/$LIBUDEV_1" "/opt/google/chrome/$LIBUDEV_0"
  elif [ -f "/usr/$LIBDIR/$LIBUDEV_1" ];
  then
    ln -snf "/usr/$LIBDIR/$LIBUDEV_1" "/opt/google/chrome/$LIBUDEV_0"
  else
    echo "$LIBUDEV_1" not found in "$LIBDIR" or "/usr/$LIBDIR".
    exit 1
  fi
}

remove_udev_symlinks() {
  rm -rf "/opt/google/chrome/$LIBUDEV_0"
}

remove_udev_symlinks
add_udev_symlinks
Owner

ibdknox commented May 17, 2013

So I just cracked open the .deb for chrome and this is what they do:

# Fedora 18 now has libudev.so.1. http://crbug.com/145160
# Same for Ubuntu 13.04. http://crbug.com/226002
LIBUDEV_0=libudev.so.0
LIBUDEV_1=libudev.so.1

add_udev_symlinks() {
  get_lib_dir
  if [ -f "/$LIBDIR/$LIBUDEV_0" -o -f "/usr/$LIBDIR/$LIBUDEV_0" -o -f "/lib/$LIBUDEV_0" ]; then
    return 0
  fi

  if [ -f "/$LIBDIR/$LIBUDEV_1" ]; then
    ln -snf "/$LIBDIR/$LIBUDEV_1" "/opt/google/chrome/$LIBUDEV_0"
  elif [ -f "/usr/$LIBDIR/$LIBUDEV_1" ];
  then
    ln -snf "/usr/$LIBDIR/$LIBUDEV_1" "/opt/google/chrome/$LIBUDEV_0"
  else
    echo "$LIBUDEV_1" not found in "$LIBDIR" or "/usr/$LIBDIR".
    exit 1
  fi
}

remove_udev_symlinks() {
  rm -rf "/opt/google/chrome/$LIBUDEV_0"
}

remove_udev_symlinks
add_udev_symlinks
@nullbio

This comment has been minimized.

Show comment Hide comment
@nullbio

nullbio May 17, 2013

@ibdknox Ah, indeed it does. I didn't try symlinking in the lib folder, only in the LightTable folder. Thank you for the link.

nullbio commented May 17, 2013

@ibdknox Ah, indeed it does. I didn't try symlinking in the lib folder, only in the LightTable folder. Thank you for the link.

@kentfredric

This comment has been minimized.

Show comment Hide comment
@kentfredric

kentfredric May 17, 2013

@pobri19 yeah, the "key" to having it work in the LightTable folder is that you /also/ need to have a startup script to make it work if you choose to put the symlink there.

So either A:

  • put symlink in lighttable folder
  • use a loader script that changes LD_LIBRARY_PATH

Or B:

  • put symlink in system library path

A is preferred, but B is easier for some.

@pobri19 yeah, the "key" to having it work in the LightTable folder is that you /also/ need to have a startup script to make it work if you choose to put the symlink there.

So either A:

  • put symlink in lighttable folder
  • use a loader script that changes LD_LIBRARY_PATH

Or B:

  • put symlink in system library path

A is preferred, but B is easier for some.

@Gonzih

This comment has been minimized.

Show comment Hide comment
@Gonzih

Gonzih Jun 11, 2013

Fix for OpenSUSE 12.3 x64
sudo ln -s libudev.so.1 /usr/lib64/libudev.so.0

Gonzih commented Jun 11, 2013

Fix for OpenSUSE 12.3 x64
sudo ln -s libudev.so.1 /usr/lib64/libudev.so.0

@MasseGuillaume

This comment has been minimized.

Show comment Hide comment
@MasseGuillaume

MasseGuillaume Aug 9, 2013

in ubuntu 13.0.4 google chrome is installed in /opt/google/chrome so
sudo ln -s /opt/google/chrome/libudev.so.0 /usr/lib/libudev.so.0

in ubuntu 13.0.4 google chrome is installed in /opt/google/chrome so
sudo ln -s /opt/google/chrome/libudev.so.0 /usr/lib/libudev.so.0

@yuanxu

This comment has been minimized.

Show comment Hide comment
@yuanxu

yuanxu Oct 12, 2013

Just modify the LightTalbe file:
FOLDERS="/lib /lib/x86_64 ..." to:

FOLDERS="/lib64"

yuanxu commented Oct 12, 2013

Just modify the LightTalbe file:
FOLDERS="/lib /lib/x86_64 ..." to:

FOLDERS="/lib64"

@ibdknox

This comment has been minimized.

Show comment Hide comment
@ibdknox

ibdknox Oct 13, 2013

Owner

@yuanxu I'll add /lib64 to the list, thanks!

Owner

ibdknox commented Oct 13, 2013

@yuanxu I'll add /lib64 to the list, thanks!

@ibdknox ibdknox closed this Nov 11, 2013

@iperdomo

This comment has been minimized.

Show comment Hide comment
@iperdomo

iperdomo Nov 12, 2013

👍

👍

@jleclanche

This comment has been minimized.

Show comment Hide comment
@jleclanche

jleclanche May 17, 2014

This is still an issue on arch linux, which creates a dependency on libudev.so.0. Is there no way to fix this?

This is still an issue on arch linux, which creates a dependency on libudev.so.0. Is there no way to fix this?

@jdnier

This comment has been minimized.

Show comment Hide comment
@jdnier

jdnier Jun 9, 2014

It's a problem on Ubuntu 14.04. @MasseGuillaume 's solution, above, works.

sudo ln -s /opt/google/chrome/libudev.so.0 /usr/lib/libudev.so.0

jdnier commented Jun 9, 2014

It's a problem on Ubuntu 14.04. @MasseGuillaume 's solution, above, works.

sudo ln -s /opt/google/chrome/libudev.so.0 /usr/lib/libudev.so.0

@ThomasChilinski

This comment has been minimized.

Show comment Hide comment
@ThomasChilinski

ThomasChilinski Jun 11, 2015

The Binary distribution of Juno. ships with it's own statically linked libudev.so. It's "basically" Light Table with the Juno plugin installed.

The Binary distribution of Juno. ships with it's own statically linked libudev.so. It's "basically" Light Table with the Juno plugin installed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment