Posted by: sevencapitalsins | 1 Novembre 2007

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

EDIT!!! The right way to fix this (and similar problems) is:

emerge gentoolkit
revdep-rebuild -X

It appears that the libexpat problem was caused by Gentoo developers releasing too many updates without cross-checking them.

I got this error in Gentoo, after doing an “emerge world”. I’m using an AMD64 Turion laptop.

/usr/bin/dbus-daemon: error while loading shared libraries: libexpat.so.0: cannot open shared object file: No such file or directory

dbus didn’t start, so hald couldn’t start, and finally kpowersave wasn’t able to read the battery state.

You’ll agree with me that it is pretty annoying if you have a 3h25m battery life laptop.

Here’s how I solved the problem:

1) First of all, I found the path to libexpat.so: it’s /usr/lib/libexpat.so

root@smokey# ls -l /usr/lib/libexpat* -rw-r--r-- 1 root root 250620 Oct 29 14:17 /usr/lib/libexpat.a -rw-r--r-- 1 root root    795 Oct 29 14:16 /usr/lib/libexpat.la lrwxrwxrwx 1 root root     17 Oct 29 14:17 /usr/lib/libexpat.so -> libexpat.so.1.5.2 lrwxrwxrwx 1 root root     17 Oct 29 14:17 /usr/lib/libexpat.so.1 -> libexpat.so.1.5.2 -rwxr-xr-x 1 root root 141456 Oct 29 14:17 /usr/lib/libexpat.so.1.5.2

2) As you can see, there’s no such thing as a libexpat.so.0 in /usr/lib. But there is a libexpat.so.1 referenced by libexpat.so itself. So I made a symbolic link named libexpat.so.0 pointing to libexpat.so:

root@smokey#  ln -s /usr/lib/libexpat.so /usr/lib/libexpat.so.0

bell.png Be warned: this may not be the right thing to do. I should have checked the configuration file of the dbus daemon, and changed it to reference libexpat.so instead of libexpat.so.0. But as you may guess i was pissed enough to dig deeply into crappy conf files. And what if there was another app requiring libexpat.so.0? You can never guess when a developer/mantainer will fail you.

3) Finally, fire up those lazy dbus and hald daemons:

root@smokey# /etc/init.d/dbus start  * Starting D-BUS system messagebus ... root@smokey# hald start

Tch… That was easy, man. happy And my battery is the best, you’ll never beat me in powersaving.

Risposte

Hey Seven,

I had the exact same error message on Gentoo when trying to restart Apache.

I made a symbolic link like you sugested (I had same versions as you with ls -l) and it worked perfectly.

Thx !

Fred

Strange, isn’t it? I wonder why those apps link themselves to libexpat.so.0 instead of libexpat.so as one would expect.

Glad it solved your problem.

I’m actually having the same issue right now i got it after running out of diskspace on a yum upgrade of Fedora 7 to Fedora 8. I think its what’s causing my lack of Gui currently as well (i’m using lynx :( ) i’ll made the link but i haven’t tried it yet wish me luck!

It works got X up and running again and everything.
its so much better looking this way
Thanks a bunch.

I’m glad it worked. I ask myself why developers make those crazy things. There must be a reason, surely.

thx! it worked for me!

Thanks for this post, I had the same problem on my gentoo server and this fixed it!

No! You just run “revdep-rebuild”

This method can break stuff! =(

thank you sooooooo much, it worked perfectly !! :)

revdep-rebildnot always work But this method helped me :) durning gentoo installation

smokey luca # revdep-rebuild
bash: revdep-rebuild: command not found

So now I ask you: why?

ok i found out by myself…

emerge gentoolkit

and now revdep-rebuild is here

Hi, symlinking could harm your system (or at least other apps)

Simply copying the file to rename it does the trick

here for ubuntu
cp libexpat.so.1 libexpat.so.0

As I said, that may not be the right thing to do,
and in the comments i have seen that revdep-rebuild is the best :)

You simply have to rebuild all your dependencies…

I guess I should edit the post, but I’m lazy.

I have the same problem. But .. I found libexpat.so.0 in /usr/lib32. Whereas /usr/lib is a symlink to /usr/lib64, so that’s where libexpat.so.1 lives.

I’m not sure what this means though … anyone have an idea for a cleaner fix?

Found what appears to be a fix. I don’t know if the first step matters but I saw in a forum that it might be an issue:

emerge gettext

Then

revdep-rebuild -X –library libexpat.so.1

The so.1 version is in /usr/lib64, while the so.0 version is in /usr/lib32. This worked for me.

double dash before library

Leave a response

Your response:

Categorie