...making Linux just a little more fun!

<-- 2c Tips | TAG Index | 1 | 2 | 3 | 4 | Knowledge Base -->

The Answer Gang

By Jim Dennis, Jason Creighton, Chris G, Karl-Heinz, and... (meet the Gang) ... the Editors of Linux Gazette... and You!



(?) Missing libraries

...and how to find them

From Benjamin A. Okopnik

Answered By: Jimmy O'Regan, Neil Youngman, Peter Knaggs

All of a sudden, lots and lots of stuff - including 'vi' - is crashing when I try to bring it up. The error message I get is "error while loading shared libraries: libpangocairo-1.0.so.0: cannot open shared object file: No such file or directory".

Worst of all, grepping the Debian ls-lR doesn't show any such thing - and searching the Net has lots of people having the same problem and not being able to find a package that contains it. This is not sounding good.

Folks, if any of you could take a look in your /usr/lib (that's where 'strace' tells me these progs are looking for it) and send me a copy of your libpangocairo-1.0.so.0 - assuming that somebody somewhere has it - I'd be very grateful. Meanwhile, I'm quite annoyed and puzzled - how the heck can so much stuff depend on a lib that's not available???

Sigh. I hope I don't end up having to reinstall my entire system. That would be a really, really big problem while I'm on the road.

(?) Update: I've found an RPM that contains libpangocairo - presumably, it's something near what I need. Converting it wasn't useful, since it was going to put the files into a different directory - so I just copied out the files and put'em into /usr/lib.

Result: well, I've got Vim, Mozilla, and Firefox back. On the other hand, "mdh" (my MailDoHickey from Freshmeat that I've been using for a year or more) segfaults; so does "gqview".

My best guess as to the cause of this: earlier, I did an "apt-get update" and "apt-get dist-upgrade", and I recall seeing "libc" (and a few other libs) go flying by in the list of installed packages. If that's what it is, then I'm a bit shocked: I've never had Debian break my install before, simply via an update.

More tomorrow, since it's almost 2a.m. here.

(!) [Jimmy] New version of gvim? Pango is Gnome's framework for internationalised text (bidi, strange fonts, etc.), Cairo is a vector drawing library (like DPS or Apple's Display PDF (Quartz?)). All text in Gtk is now rendered through Pango, so everything that depends on Gtk in any way is going to depend on it.
It doesn't seem to be in Debian yet.

(?) Ah. I see.

A few days ago, the maintainer of Jpilot got back to me about a bug that I'd filed, and asked me to recompile Jpilot from source with the latest libpisock library. However, Debian's "official" method of creating a package from source is this nightmarish chase of dependencies, all alike... and Gtk+, Cairo, Pango, and a few other things (all from pretty much the same place - the gtk.org FTP server.)

However, everything worked OK back then - including the new version of JPilot. Something in the recent update must be conflicting with the "cutting edge" libs.

It still isn't looking good. I've tested a few other GTK-based apps - gtkpool, gtksee, gtop - and they work, although gtop throws out a cryptic warning:

glibtop: glibtop_get_swap (): Client requested field mask 0001f, but
only have 00007.

I have no idea what all those libs may have overwritten. Fixing it is going to take some thought. :|

(!) [Jimmy] Um... specifically, the Cairo backend for Pango doesn't seem to be in Debian yet, though Pango is.

(?) So, now that I'm actually awake, and possess a functioning brain - in contrast to last night - I have a plan of attack that should let me get past all this bull with the grace of a matador (and without using OLE even once.)

1) Pick a bunch of GTK-based apps and run each one. Add those that fail to a list. Then:

for app in $list
do
       ldd `which $app` |perl -wlne's/^.* => (\S+) .*/$1/;/gtk|pango|cairo/&&print'>>list.txt
       sort -uo list.txt list.txt
done

while read n; do readlink $n; done < list.txt

This should give me a list of all the relevant libs - running this for 'mdh' and 'gtk-gnutella' already shows some promise - that may need to be reinstalled. It may require that I manually remove the offending lib (sometimes, installing the right version doesn't do anything unless the old lib is removed), but that shouldn't be too difficult; the list won't be all that long.

Running the above for 'mdh' and 'gtk-gnutella' shows:

/usr/lib/libcairo.so.1
/usr/lib/libcairo.so.2
/usr/lib/libgtk-x11-2.0.so.0
/usr/lib/libpango-1.0.so.0
/usr/lib/libpangocairo-1.0.so.0
/usr/lib/libpangoft2-1.0.so.0
/usr/lib/libpangox-1.0.so.0
/usr/lib/libpangoxft-1.0.so.0

I'm betting that one of those - libgtk-x11-2.0.so.0, anybody? - is the bugger that's busting my chops. More tests later; gotta run to work NOW.

(?) Update: got it fixed. Most likely.  :) At least, GTK apps now run without complaining.

I looked at the list that I got as a result, and ran "dlocate" over the "root name" bits (everything up to the first '.'); other than the obvious, most of the rest pointed to libglib2.0-0. I reinstalled it and removed the newer versions - i.e., the current lib names mostly look like "libpangoft2-1.0.so.0.801.1", while the newer (broken) ones look like "libpangoft2-1.0.so.0.1001.0" - and life is good again. Whew.

I'm going to be doing more testing - i.e., by removing "libpangocairo", which should not be getting pulled in by anything - but it seems all right now.

(!) [Neil] There was a neat tip on TAG a while back about the LD_DEBUG environment variable. I think it could be useful in identifying the exact problem.
neil ~ 15:08:12 501 > LD_DEBUG=help ls
Valid options for the LD_DEBUG environment variable are:

 libs        display library search paths
 reloc       display relocation processing
 files       display progress for input file
 symbols     display symbol table processing
 bindings    display information about symbol binding
 versions    display version dependencies
 all         all previous options combined
 statistics  display relocation statistics
 unused      determined unused DSOs
 help        display this help message and exit

To direct the debugging output into a file instead of standard output
a filename can be specified using the LD_DEBUG_OUTPUT environment variable.
neil ~ 15:50:43 502 >

(?) Oh, good one! I wish I'd remembered it. I used 'strace' to see what was going on; unfortunately, it didn't show enough detail to be of use. The above may well do that; I'll use it to do a little troubleshooting, just to make sure that this is resolved. Thanks, Neil!

(!) [Peter] Ulrich Drepper has a quite readable guide to writing shared libraries, he's been maintaining it for quite a while now and in Jan 2005 put out this: http://people.redhat.com/drepper/dsohowto.pdf It's probably more intended for folks actually writing shared libs in the first place, but it's a good one for debugging

This page edited and maintained by the Editors of Linux Gazette
HTML script maintained by Heather Stern of Starshine Technical Services, http://www.starshine.org/


Each TAG thread Copyright © its authors, 2006

Published in issue 122 of Linux Gazette January 2006

<-- 2c Tips | TAG Index | 1 | 2 | 3 | 4 | Knowledge Base -->
Tux