Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

When I run a process that links to a shared library at runtime (linked when the process starts, not linked later with dlload()), where does it look for that shared library (.so) file other than LD_LIBRARY_PATH?

Background:

I have some C++ code that I wrote that uses a particular third-party library. I have installed the library and compiled my code on two different platforms, both Ubuntu but different versions, and different versions of gcc as well. The library was compiled and installed from source, and is located in /usr/local/lib on both platforms. When I compile my code, I link with the pkg-config --libs parameters for the third-party library and I've verified that pkg-config --libs returns the exact same thing on both platforms.

My code compiles successfully on both platforms, and LD_LIBRARY_PATH is not defined (or defined as empty: "") on both platforms. However, when I run it on one platoform it works fine, and on the other I get this error:

error while loading shared libraries: libthrift-0.9.0.so: cannot open shared object file: No such file or directory

Funnily enough, the ones that doesn't work is the newer version of Ubuntu and gcc. :/

So I'm trying to figure out how the working one is able to locate the library, so that I can make the broken one locate the library in the same way. (i.e., without setting LD_LIBRARY_PATH)

Update:

Here's my output from cat /etc/ld.so.conf.d/*

...on the working (older) system:

/usr/lib/mesa
/usr/lib32/mesa
/usr/lib/alsa-lib
# libc default configuration
/usr/local/lib
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu

...on the broken (newer) system:

# libc default configuration
/usr/local/lib
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/mesa
share|improve this question
1  
I think those places are defined in /etc/ld.so.conf.d/*.conf, but I'm not sure of it. –  Salem Sep 25 '13 at 21:18
    
Seems like it, but see my update to the OQ for the contents of those files... So it looks like it should find /usr/local/lib/libthrift-0.9.0.so but still it gives the error error while loading shared libraries: libthrift-0.9.0.so: cannot open shared object file: No such file or directory... Is there any reason it would not pick up a directory from /etc/ld.so.conf.d/*.conf? –  Dave Lillethun Sep 25 '13 at 21:32
1  
Try to run sudo ldconfig -v as suggested below. If it still does not work update your question with the output of ldd /path/to/your/application. –  Salem Sep 25 '13 at 21:45
add comment

1 Answer

up vote 2 down vote accepted

This whole path business is related to something called multi-arch. Basically it's to allow you to have 32bit and 64bit libraries on the same system.

After you copied the file, did you happen to run ldconfig?

ldconfig  creates,  updates,  and removes the necessary links and cache
       (for use by the run-time linker,  ld.so)  to  the  most  recent  shared
       libraries  found  in  the directories specified on the command line, in
       the file /etc/ld.so.conf, and in the trusted directories (/usr/lib  and
       /lib).   ldconfig  checks the header and file names of the libraries it
       encounters when determining which  versions  should  have  their  links
       updated.  ldconfig ignores symbolic links when scanning for libraries.
share|improve this answer
    
I ran sudo ldconfig and that fixed the problem! (Didn't need to recompile my code or anything...) I just want to understand, though... You said "After you copied the file," but I did not copy a file. Do you mean after I built & installed the library, or after I compiled my program? –  Dave Lillethun Sep 25 '13 at 22:04
    
After you placed it where you placed it. Basically a library cache is built. I think rebooting may also rebuild the cache. –  Matt H Sep 26 '13 at 1:35
    
I may be mistaken, but I believe I had rebooted since installing the library... However, sudo ldconfig did the trick. Is this something libraries often automatically run for your as part of their install, and this one for some reason didn't? Just wondering why I don't "normally" have to do this, but did only in this case... –  Dave Lillethun Sep 26 '13 at 16:28
    
Usually the package install will run ldconfig during the install process I think. Maybe the version on your newer distro isn't doing it for some reason. –  Matt H Sep 26 '13 at 21:38
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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