EDIT!!! The right way to fix this (and similar problems) is:
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
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. And my battery is the best, you’ll never beat me in powersaving.