If you’ve used and built packages from source, chances are you’ve run into some derivation of this dreadful message:

libtool: link: `/usr/lib/libgnomevfs-2.la' is not a valid libtool archive

Unfortunately, there are a few potential causes ranging from broken packages to missing packages, but in general, they are the result of broken dependencies (missing packages are broken dependencies, after all!). Read on about some potential workarounds and solutions!

First, Some Background

Before going into generic solutions, I need to give you a little background related to my problem.

After quite some time of leaving loads–and I really mean loads–of junk on my file server, I finally decided to clean it up. I had ancient builds of Gnome and its dependencies, Firefox 1.0.7 (no, I’m not kidding), and countless other packages I had no use for. So, I removed them. I was planning on updating world on my Gentoo install anyway, so to trim the excessive downloads (which would’ve amounted to 800MiB), I decided to remove packages I wasn’t using. It seemed like a good idea at the time. Unfortunately, I didn’t exactly plan ahead.

As it turns out, libtool keeps a list of active dependencies in /usr/lib/*.la for each installed library. As libraries are removed, some *.la files may still contain references to the now-missing dependencies. In my particular case, libgnomevfs-2.la was still being referenced every time I attempted to upgrade ImageMagick.

Climbing the Deps Ladder

This is where the annoying part starts to surface. If you really want to resolve the issue and it’s not the fault of whatever package you’re installing (or gcc for that matter) and you’ve tried updating libtool, you need to start examining everything under /usr/lib. In my particular case, I knew that ImageMagick was referencing libgnomevfs somehow but precisely how was a mystery. grep’ing through /usr/lib/*.la revealed the culprit referenced by two other libraries:

/usr/lib/libgtkhtml-3.8.la:dependency_libs=' ... /usr/lib/libgnomevfs-2.la 
/usr/lib/librsvg-2.la:dependency_libs=' /usr/lib/libgnomevfs-2.la ...

Clearly, I must have missed something during my package culling:

[sagittarius:bshelton]# qfile /usr/lib/librsvg-2.so
gnome-base/librsvg (/usr/lib/librsvg-2.so)

[sagittarius:bshelton]# qfile /usr/lib/libgtkhtml-3.8.so
gnome-extra/gtkhtml (/usr/lib/libgtkhtml-3.8.so)

Yep. Dependencies suck when they don’t work. Worse, when you’re trying to clean up unused packages and forget about the --depclean emerge flag, you wind up having to do a lot of extra work. (Be careful with --depclean, though; it can remove packages you want to keep!)

I read somewhere while searching for a quick fix (hah!) that removing the *.la files from /usr/lib is sometimes the fastest option. I’m not so sure I’d recommend this approach because it can encourage breakage of other packages and sidelines the initial problem. If you’re running into this problem after having removed packages or committed an update where package names have changed, you’re probably forgetting to rebuild or remove something else. In this case, consider the warning to be sending an important message: You’re going to need to look around a little further. If you don’t figure out what you’re overlooking, you might run into other broken packages. Or, best case (under Gentoo), you might wind up discovering that updating world pulls in packages it shouldn’t be.

I also discovered that ImageMagick was attempting to build with the X USE flag still set. Perhaps that was why it kept attempting to search for librsvg. Removing librsvg and the dependency on X was enough to build ImageMagick without further libtool-related gripes.

When in Doubt Examine the Errors

If there’s ever any doubt about what might be causing your problem, don’t simply take libtool’s word for it: look around! You’ll probably need to use grep, and if you encounter a library you thought you removed and didn’t, remove it. If you need that library, rebuild it. Sometimes the cache can be invalidated by changes to the system and the best way to correct it is to simply rebuild the affected libraries.

Then again, there’s always revdep-rebuild under Gentoo. Of course, there’s also the possibility that revdep-rebuild might fail with libtool error messages…

Other Possibilities

There are other possible sources of libtool-related grief. If you’re encountering a specific error related to libstdc or a new build of KDE/Gnome, you might need to glance around the mailing lists and forums of your favorite distribution. libstdc*-related errors can usually be dealt with by either installing the particular version of libstdc++ your application requires. Worst case, you might need to grab an updated version of gcc, libtool, and glibc–or rebuild them. Rebuilding libtool is particularly necessary if you’ve updated other parts of the tool-chain, like gcc. Never build only a small part of it; if you do, you risk breaking other parts of the system in mysterious ways. On the other hand, it’s a useful learning experience that can be handy when trouble shooting other platforms.

Oh, and it’s late. Sleep sounds really good about now.