Miro on OpenSuse a DLL Hell fix

A couple weeks ago I posted about switching to Miro the Internet TV program running on Linux from another app on WinXP. Well a day or two after I wrote that post, OpenSuse 10.3 had some mandatory updates. Miro was running at the time so I exited Miro and waited for the updates to finish. No reboot was requested so I clicked the Miro icon, a little processor usage then nothing. I rebooted, tried again and the problem remained, time to open a console to see what’s going on.

paulh@linux1:~> miro
/usr/lib/xulrunner-1.8.1.4
Traceback (most recent call last):
File "/usr/bin/miro.real", line 123, in <module>
startapp()
File "/usr/bin/miro.real", line 58, in startapp
import singleclick
File "/usr/lib/python2.5/site-packages/miro/singleclick.py", line 36, in <module>
import app
File "/usr/lib/python2.5/site-packages/miro/app.py", line 610, in <module>
import frontend
File "/usr/lib/python2.5/site-packages/miro/frontend.py", line 50, in <module>
import MozillaBrowser
ImportError: libgtkembedmoz.so: cannot open shared object file: No such file or directory

I see the last line and knowing there was just an OS update I immediately think DLL Hell. I know, most people only use that term for Windows *.DLL files but, I use it whenever I hit  a problem with shared code in any OS. Actually I can’t remember the last time I had to deal with DLL Hell in Windows or Linux. Both Microsoft and the Linux community have done a great job of eliminating dependency issues. Since I’m lazy when it comes to fixing PC problems these days I simply searched Google for ImportError: libgtkembedmoz.so. Many plausible looking solutions are in the results and I spend a bit of time trying out some of them but no luck.

When I get back to working on the problem a few days later I try out some more suggestions found on the net. Still no luck, no time left to play around that night and I want to see the new Cranky Geeks episode. Here’s where the cross platform feature of Miro pays off, I put it on the Media Center PC and tell Miro to use the Samba share for storage. I get my Cranky Geeks fix and plan to revisit the problem later.

Tonight I decide to try again but this time I actually read the whole console output instead of just the error line. There’s the answer in the first line, the OpenSuse package for Miro is looking for xulrunner-1.8.1.4 and I have xulrunner-1.8.1.10 and a symbolic link for xulrunner-1.8.1. I take the easy way out and just create a symlink for xulrunner-1.8.1.4 (ln -s /usr/lib/xulrunner-1.8.1.10 /usr/lib/xulrunner-1.8.1.4).  That does the trick and Miro launches again on OpenSuse. 🙂 I’m assuming the recent OS update upgraded xulrunner-1.8.1.4 to xulrunner-1.8.1.10.

I had seen a thread about this issue on the Miro forums before so I head over to post my fix. What do I find, pturner7 posted the following fix two days ago.

Looking in this folder /usr/lib/ reveals that I have xulrunner-1.8.1.10
To fix this, edit as root the file > /usr/bin/miro
Change both instances of /usr/lib/xulrunner-1.8.1.4 to /usr/lib/xulrunner-1.8.1.10 (or whatever version is residing there).
That should get it past the .so error.

The problem was that the OpenSuse package builder used a hard coded library reference in the startup script creating this DLL Hell.

Comments closed 7/18/08 to slow the spam