Tuesday, January 31, 2012

Debugging load library path issues
If you get a problem with a library that can't find another, you should check the library's dependencies and make sure that the directory in which the missing library resides is part of the load library path.

One example of this problem, that I experienced recently, occurred when the Magick.so library was unable to open the libMagick.so.10 library. The error message was as follows:

Can't load '/usr/lib/perl5/site_perl/5.8.7/i686-linux/auto/Image/Magick/Magick.so' for module Image::Magick: libMagick.so.10: cannot open shared object file: No such file or directory at /usr/lib/perl5/5.8.7/i686-linux/DynaLoader.pm line 230. at (eval 113) line 1 Compilation failed in require at (eval 113) line 1. BEGIN failed--compilation aborted at (eval 113) line 1.
Find out library dependencies with ldd

In the words of the man page, ldconfig will configure dynamic linker run time bindings. Add your missing library to the bindings with the following command:

ldconfig /path/to/add
For our libMagick example, this would be:

username@localhost [~]# ldconfig /usr/local/lib
You can see a list of librarys that are being used with the -p flag.

username@localhost [~]# ldconfig -p
907 libs found in cache `/etc/ld.so.cache'
libzvt.so.2 (libc6) => /usr/lib/libzvt.so.2
libzvt.so (libc6) => /usr/lib/libzvt.so
libzip.so (libc6, hwcap: 0x0001000000000000) => /opt/blackdown-jdk-1.4.2.03/jre/lib/i386/libzip.so
libz.so.1 (libc6) => /lib/libz.so.1
libz.so (libc6) => /lib/libz.so
libxslt.so.1 (libc6) => /usr/lib/libxslt.so.1
libxslt.so (libc6) => /usr/lib/libxslt.so
[...cut...]
If you want to make make the changes more permanent, so that you don't have to remember to specify the directory next time you run the command, you can add it to the /etc/ld.so.conf file, though different linux distributions manage this file in different ways.