22Feb

Fix library dependency error in XBMC on Raspberry Pi

If you have installed Mopidy on your RaspBMC you probably noticed that XBMC won’t start when you reboot the Pi. Technically it’s not Mopidy that causes XBMC to crash, but rather some package dependencies that are introduced when you install it. More precisely these:

libtag1-vanilla:armhf libtag1c2a:armhf gstreamer0.10-plugins-good:armhf

The problem is that Mopidy installs an older version of these packages than the one XBMC is dependent on, and it puts these packages in  /usr/lib/arm-linux-gnueabihf/. This folder has precedence over the XBMC lib folder which is located in /home/pi/.xbmc-current/xbmc-bin/lib/xbmc/system/, and this causes XBMC to pick up the wrong libraries.

This problem is not caused only by Mopidy, but any other package that installs another version of these libraries.

If you see the following error in your /var/log/messages, it is most likely caused by this dependency error:

raspbmc xbmc: /home/pi/.xbmc-current/xbmc-bin/lib/xbmc/xbmc.bin: symbol lookup error: /home/pi/.xbmc-current/xbmc-bin/lib/xbmc/xbmc.bin: undefined symbol: _ZTIN6TagLib8IOStreamE

To make sure this is the case, you can run the following command in the terminal:

ldd .xbmc-current/xbmc-bin/lib/xbmc/xbmc.bin | grep libtag

… and the output should show something like this:

libtag.so.1 => /usr/lib/arm-linux-gnueabihf/libtag.so.1 (0xb5a92000)

Here we can see that XBMC is actually trying to pickup the libtag.so.1 in /usr/lib/arm-linux-gnueabihf/ instead of in /home/pi/.xbmc-current/xbmc-bin/lib/xbmc/system/. Now that we know this, we can try to fix the problem.

 

Solutions

Bad solution

Before I managed to figure out what caused this problem, I searched high and low for a solution. I came across a few “fixes”, but all of them were kind of dirty hacks that only temporarily fixed the problem.

For example, several people suggested to do something like this to remove the problematic packages:

sudo dpkg --purge libtag1-vanilla:armhf libtag1c2a:armhf gstreamer0.10-plugins-good:armhf
or

sudo dpkg -r --force-depends libtag1-vanilla:armhf libtag1c2a:armhf gstreamer0.10-plugins-good:armhf

The problem with these solutions is that this will cause apt-get to complain every time you want to update or upgrade the system. With this solution, before you can do anything in apt-get, you would have to re-install the missing dependencies, do whatever you want to do, and then remove them again. Not very good!

Better solution

The best solution would be for Mopidy to change its dependency version, but until then the problem can be circumvented using symbolic links. 

To make sure XBMC is using the right dependency version, simply add a symbolic link between the two libraries:

sudo ln -sf /home/pi/.xbmc-current/xbmc-bin/lib/xbmc/system/libtag.so.1 /usr/lib/arm-linux-gnueabihf/libtag.so.1

This will make XBMC pick up the right libraries again. To make the symbolic link persistent on reboot, you have to add the command to your /etc/rc.local.

I hope this helps other people facing the same problem, and if anyone have a better solution to this problem, feel free to share it in the comments.

 

This fix is confirmed to work on the following setup: 

Linux raspbmc 3.10.24 #2 PREEMPT Mon Dec 23 05:18:12 UTC 2013 armv6l GNU/Linux
Mopidy version 0.18.3

Share this Story

About Robin Bellini Olsson

Software engineer, big thinker, and co-founder of Noeit.
Political views: Android > iOS

9 comments

  1. does this fix both xbmc and mopidy?

  2. It works, thanks! unfortunately after playing a movie, it seems that xbmc restarts itself and some other program has removed the symlink. If i create it again, it works again until the next movie.

  3. Hi Robin, thanks a heap! This worked perfectly – I can now boot into XBMC once more!

  4. /etc/rc.local doesn’t work on debian based machines the way it used to.

    The proper way to persist this is to edit
    /etc/ld.so.conf.d/arm-linux-gnueabihf.conf and add “/home/pi/.xbmc-current/xbmc-bin/lib/xbmc/system” at the top
    so that XBMC looks there first and finds the proper version.

    Although I really don’t understand this trend of vendoring in stuff….I see it all the time
    and it only brings trouble…There’s a reason we have package managers. Use them.

  5. I followed Den Bertovic instructions and it’s now working fine for me too
    Thank you very much !

  6. Any updates for kodi/osmc? The fix is not working for osmc.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

© 2014 Noeit - All Rights Reserved.