[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#783637: Installation fails because starting colord fails on missing libudev.so.0



Michael Lager, le Wed 06 May 2015 14:32:23 +0100, a écrit :
> The reason the upgrade failed when starting X was that colord couldn't start
> because it was missing libudev.so.0 as reported:
> 
> "/usr/lib/colord/colord: error while loading shared libraries: libudev.so.0:
> cannot open shared object file: No such file or directory"
> 
> colord also depends on libusb-1.0.so.0 in /usr/local/lib, see below:
> 
> $ ldd /usr/lib/colord/colord|grep -E libudev\|libusb
>     libusb-1.0.so.0 => /usr/local/lib/libusb-1.0.so.0 (0x00007f08bcd66000)
>     libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007f08bb256000)
> 
> So why does colord complain about missing libudev.so.0 when ldd says it depends
> on libudev.so.1?

Because colord also depends on libusb-1.0.so.0, and you have a
/usr/local/lib/libusb-1.0.so.0 which comes from whatever you installed
by hand. And *that /usr/local/lib/libusb-1.0.so.0 depends on
libudev.so.0. That was the whole point of the objdump magic loop I asked
you to run:

objdump -x /usr/lib/colord/colord | grep NEEDED
  NEEDED               libusb-1.0.so.0
/usr/local/lib/libusb-1.0.so.0
  NEEDED               libudev.so.0

*That* thing is the culprit. And it's not Debian which shipped it, you
installed it by hand somehow.

> So I think colord is looking for libusb-1.0.0.so.0 in the wrong place,

No, /usr/local/lib is expected to be looked for before /usr/lib, that's
completely normal.

> using /
> usr/local/lib although you say nothing in debian uses /lib/local.

Nothing in Debian *provides* anything int /usr/local/lib. So your
/usr/local/lib/libusb-1.0.so.0 does not come from Debian. So the bug is
not in Debian.

> libusb-1.0.so.0 is provided by package libusb-1.0-0:

/lib/x86_64-linux-gnu/libusb-1.0.so.0 is, but
/usr/local/lib/libusb-1.0.so.0 is not.

> A symlink in /usr/local/lib to /usr/x86_64-linux-gnu/libusb-1.0.0.so.0 should
> be a valid fix,

It would be an odd fix. Just remove these libusb files from
/usr/local/lib.

> (Others have had similar issues elsewhere: eg [1]https://github.com/LightTable/
> LightTable/issues/161, and been rightly warned off linking different versions
> of libraries.)

Yes. Mixing library versions is just asking for even more obscure bugs.

> Probably this needs to be moved to a colord bug?

Again, colord is not a culprit at all here. Whatever made you put
/usr/local/lib/libusb-1.0.so.0 is.

Samuel


Reply to: