Linux error while loading shared libraries: cannot open shared object file: No such file or directory


Program is part of the Xenomai test suite, cross-compiled from Linux PC into Linux+Xenomai ARM toolchain.

# echo $LD_LIBRARY_PATH                                                                                                                                          
# ls /lib                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   
# ./clocktest                                                                                                                                                    
./clocktest: error while loading shared libraries: cannot open shared object file: No such file or directory                                 

Edit: OK I didn't notice the .1 at the end was part of the filename. What does that mean anyway?

1/26/2009 6:22:44 PM

Accepted Answer

While what I write below is true as a general answer about shared libraries, I think the most frequent cause of these sorts of message is because you've installed a package, but not installed the "-dev" version of that package.

Well, it's not lying - there is no in that listing. You probably need to re-configure and re-build it so that it depends on the library you have, or install whatever provides

Generally, the numbers after the .so are version numbers, and you'll often find that they are symlinks to each other, so if you have version 1.1 of, you'll have a real file, and symlinks and pointing to the And if you install version 1.1 without removing the other one, you'll have a, and and will now point to the new one, but any code that requires that exact version can use the file. Code that just relies on the version 1 API, but doesn't care if it's 1.0 or 1.1 will specify As orip pointed out in the comments, this is explained well at

In your case, you might get away with symlinking to No guarantees that it won't break your code and eat your TV dinners, though.

5/22/2018 8:09:50 AM

Here are a few solutions you can try:


As AbiusX pointed out: If you have just now installed the library, you may simply need to run ldconfig.

sudo ldconfig

ldconfig creates the necessary links and cache to the most recent shared libraries found in the directories specified on the command line, in the file /etc/, and in the trusted directories (/lib and /usr/lib).

Usually your package manager will take care of this when you install a new library, but not always, and it won't hurt to run ldconfig even if that is not your issue.

Dev package or wrong version

If that doesn't work, I would also check out Paul's suggestion and look for a "-dev" version of the library. Many libraries are split into dev and non-dev packages. You can use this command to look for it:

apt-cache search <libraryname>

This can also help if you simply have the wrong version of the library installed. Some libraries are published in different versions simultaneously, for example, Python.

Library location

If you are sure that the right package is installed, and ldconfig didn't find it, it may just be in a nonstandard directory. By default, ldconfig looks in /lib, /usr/lib, and directories listed in /etc/ and $LD_LIBRARY_PATH. If your library is somewhere else, you can either add the directory on its own line in /etc/, append the library's path to $LD_LIBRARY_PATH, or move the library into /usr/lib. Then run ldconfig.

To find out where the library is, try this:

sudo find / -iname *libraryname*.so*

(Replace libraryname with the name of your library)

If you go the $LD_LIBRARY_PATH route, you'll want to put that into your ~/.bashrc file so it will run every time you log in:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/library

I had the similar error, I could resolve it by giving,

sudo ldconfig -v

Hope this helps.


You need to ensure that you specify the library path during linking when you compile your .c file:

gcc -I/usr/local/include xxx.c -o xxx -L/usr/local/lib -Wl,-R/usr/local/lib

The -Wl,-R part tells the resulting binary to also look for library in /usr/local/lib at runtime before trying to use the one in /usr/lib/

Hope it will help you.


Try adding LD_LIBRARY_PATH, which indicates search paths, to your ~/.bashrc file


It works!


The reference page explains the mechanics, but doesn't explain any of the motivation behind it :-(

For that, see Sun Linker and Libraries Guide

In addition, note that "external versioning" is largely obsolete on Linux, because symbol versioning (a GNU extension) allows you to have multiple incompatible versions of the same function to be present in a single library. This extension allowed glibc to have the same external version: for the last 10 years.