Oh, RedHat – why you can’t find your library on the path

Dynamically linked programs fail to find their libraries

This bites me about once a year, so I thought I’d write down a quick note. If you’re not compiling the occasional program on a CentOS or RHEL server, you can skip this one. It’s mainly for me.

Dynamically compiled programs make use of libraries.  The library code is not compiled into the program; rather it is referenced at run-time. If those libraries cannot be found, the program may still compile. However, it will fail at run-time complaining about the missing library.

The issue is that “/usr/local/lib/” is not on the default library path on a RedHat-derived system. Smarter people than me consider this a bug. In order to fix the issue, go into the /etc/ld.so.conf.d/ directory. Create a new file called something like “local.conf”. Put the following line into it:


Save the file. Run the command /sbin/ldconfig to update the linker cache to include the /usr/local/lib directory. Re-compile the program that was having issues. See if this fixes it.

How to check if this is your issue

By the way, this will generally only bite you if you’re downloading and compiling from source. If you stick to the RPM packaged programs, you won’t have this problem. Here’s how it bit me. I wanted to use the pyqrencode library for a project. It depends upon libqrencode. I downloaded and installed libqrencode, which places a binary in /usr/local/bin/qrencode and also puts a set of library files in /usr/local/lib/. The program “qrencode” is properly linked against all of its libraries. Here’s how to test that. Run “ldd /usr/local/bin/qrencode”. You should get back something like this:

linux-gate.so.1 =>  (0x005ed000)
libqrencode.so.3 => /usr/local/lib/libqrencode.so.3 (0x00fa5000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0x00dbf000)
libc.so.6 => /lib/libc.so.6 (0x00424000)
libz.so.1 => /usr/lib/libz.so.1 (0x005cc000)
libm.so.6 => /lib/libm.so.6 (0x005a1000)
/lib/ld-linux.so.2 (0x00405000)

This shows the library and its file paths. Notice that all libraries are accounted for. So, the key command is “ldd“. It will tell you whether you’re missing any dynamically linked libraries.

In my case, when I did the usual “python setup.py install” in the pyqrencode directory and it compiled and installed the qrencode library to this file:


It did not throw any errors during this process. However, when I then tried to use the pyqrencode module in Python, it failed with libqrencode.so.3 not found errors. At that point, I ran “ldd /usr/lib/python2.4/site-packages/qrencode.so” and saw that it was failing to find libqrencode.so.3, because it was located in /usr/local/lib, which was not on the library path.

I added in local.conf, as described above,  and ran /sbin/ldconfig and then reinstalled the Python package and all was well. I hope this will save others a little bit of trouble.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s