I am developing a C++ application that uses external libraries, using gcc. For instance libtiff and libpng. I obtained these by apt-get and everything is working fine.

But then I added another third party library delivered as a stand-alone pair of .a and .so lib files. I detected that the other .so are stored in /usr/lib/x86_64-linux-gnu, and I copied the new .so there. I successfully linked my application but execution fails with the message "error while loading shared libraries: libThirdParty.so: cannot open shared object file: No such file or directory"

What am I missing ?

  • 1
    Did you try ldconfig?
    – Philippos
    May 17 at 8:07
  • @Philippos: of course not :-) May 17 at 8:23
  • Does it help to call it?
    – Philippos
    May 17 at 8:26
  • @Philippos: what do you mean ? To call what ? May 17 at 9:10
  • 1
    After installing a library, you need to run ldconfig to update the ld.so cache. May 17 at 9:35

2 Answers 2


There are two ways for a application for find its libraries:

  • The environment variable LD_CONFIG_PATH. Set it to the paths with your libs, colon-separated. Check whether it is not empty first (echo $LD_LIBRARY_PATH) and in that case expand it, for example LD_CONFIG_PATH=$LD_LIBRARY_PATH:/opt/foo/lib:/home/myself/lib. This is fine for testing or if you are neither root no a sudoer, you can add it to your shell initialization (like .zshrc) if you want it permanently. But of course it's slower to parse a variable and search for files, that's why you usually prefer the second approach:
  • After copying the libs, call ldconfig as root or with sudo. This scans standard library paths (/lib and /usr/lib or /lib64 and /usr/lib64) and paths from config file /etc/ld.so.conf and paths given as arguments to ldconfig for libraries and updates the ld.so library cache for the whole system.
  • My LD_CONFIG_PATH is empty, but the other libraries are found anyway in the same path. May 17 at 10:31
  • Yes, because they have been cached by calling ldconfig. apt did do that for you after installation. In my comment I suggested to go that way, too. Now I added the other possibility to make a complete answer out of it.
    – Philippos
    May 17 at 10:43
  • As mentioned in my comments, I cannot confirm if the problem was due to ldconfig not performed or just inappropriate file access protection. May 17 at 10:45
  • (call ldconfig as root or with sudo. This scans for libraries and updates the ld.so library cache for the whole system.) it only searches standard library locations, namely /lib, /usr/lib, (or /lib64, /usr/lib64 for x64) and then locations put in config file: /etc/ld.so.conf.
    – tansy
    May 17 at 13:23
  • @tansy Thank you. This detail was irrelevant for the OP, but I added it to the answer for future readers.
    – Philippos
    May 17 at 15:00

First, your external libraries should be installed, rather then copied to library location. Install script would put them in /usr/lib or /usr/local/lib*. That would make things easier.

And when it comes to the location of your library then I would suggest /usr/local/lib*.

Now, it (/usr/local/lib) may need to be put in /etc/ld.so.conf if you haven't done it yet and, if so, you need to run /sbin/ldconfig. It's not necessary if it's done already.

Eventually, you can check whether your library i found with: ldconfig -p | grep your_library.so.

* or /usr/lib64 or /usr/local/lib64 for x86_64

  • 1
    You have a good sense of humor. The case is already solved and you suggest a more complex solution (not counting that the problem was elsewhere). Why making it simple when you can bang your head against the wall ;-) May 17 at 15:03
  • Maye it was more general but you had said yourself, running ldconfig hadn't worked, so I elaborated on the topic bit more. Don't like it, thumb it down.
    – tansy
    May 18 at 16:11
  • Why would I change the location of the libraries "to make things easier" (especially if a .conf file needs to be updated) ?? May 19 at 8:01
  • Because you want to install external libraries. First so they are accessible, and so they can be uninstalled, reinstalled, upgraded. When you put them in place only known to you, only you can access, ur/re/install/upgrade them and other programs that use them may not be able to use them.
    – tansy
    May 19 at 19:33
  • In my context, there is no need for that, thanks. May 20 at 7:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.