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.
Traceback (most recent call last):
File "/usr/bin/miro.real", line 123, in <module>
File "/usr/bin/miro.real", line 58, in startapp
File "/usr/lib/python2.5/site-packages/miro/singleclick.py", line 36, in <module>
File "/usr/lib/python2.5/site-packages/miro/app.py", line 610, in <module>
File "/usr/lib/python2.5/site-packages/miro/frontend.py", line 50, in <module>
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-184.108.40.206 and I have xulrunner-220.127.116.11 and a symbolic link for xulrunner-1.8.1. I take the easy way out and just create a symlink for xulrunner-18.104.22.168 (
ln -s /usr/lib/xulrunner-22.214.171.124 /usr/lib/xulrunner-126.96.36.199). That does the trick and Miro launches again on OpenSuse. 🙂 I’m assuming the recent OS update upgraded xulrunner-188.8.131.52 to xulrunner-184.108.40.206.
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-220.127.116.11
To fix this, edit as root the file > /usr/bin/miro
Change both instances of /usr/lib/xulrunner-18.104.22.168 to /usr/lib/xulrunner-22.214.171.124 (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
One Reply to “Miro on OpenSuse a DLL Hell fix”
Nice! Thank you! Had the same problem.
Comments are closed.