Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

The title is pretty explicit.

I understand how to define include shared objects at linking/compile time. However I still wonder how do executables look for the shared object (*.so libraries) at execution time.

For instance my app a.out calls functions defined in the lib.so library. After compiling, I move lib.so to a new directory in my $HOME.

How can I tell a.out to go look for it there?

share|improve this question
up vote 26 down vote accepted

The shared library HOWTO explains most of the mechanisms involved, and the dynamic loader manual goes into more detail. Each unix variant has its own way, but most use the same executable format (ELF) and have similar dynamic linkers (derived from Solaris). Below I'll summarize the common behavior with a focus on Linux; check your system's manuals for the complete story.

In a nutshell, when it's looking for a dynamic library (.so file) the linker tries:

  • directories listed in the LD_LIBRARY_PATH environment variable (DYLD_LIBRARY_PATH on OSX);
  • directories listed in the executable's rpath;
  • directories on the system search path, which (on Linux at least) consists of the entries in /etc/ld.so.conf plus /lib and /usr/lib.

The rpath is stored in the executable (it's the DT_RPATH or DT_RUNPATH dynamic attribute). It can contain absolute paths or paths starting with $ORIGIN to indicate a path relative to the location of the executable (e.g. if the executable is in /opt/myapp/bin and its rpath is $ORIGIN/../lib:$ORIGIN/../plugins then the dynamic linker will look in /opt/myapp/lib and /opt/myapp/plugins). The rpath is normally determined when the executable is compiled, with the -rpath option to ld, but you can change it afterwards with chrpath.

In the scenario you describe, if you're the developer or packager of the application and intend for it to be installed in a …/bin, …/lib structure, then link with -rpath='$ORIGIN/../lib'. If you're installing a pre-built binary on your system, either put the library in a directory on the search path (/usr/local/lib if you're the system administrator, otherwise a directory that you add to $LD_LIBRARY_PATH), or try chrpath.

share|improve this answer
Great answer, thanks! ^^ – rahmu Oct 27 '11 at 9:21
On some systems, /lib64 and /usr/lib64 are used for 64 bit binaries and /lib and /usr/lib are used for 32 bit binaries. – Mark Lakata Jun 4 '15 at 18:21

For running applications the file /proc/1234/maps contains all actual dynamically linked libraries.

Where 1234 is the pid of the running executable.

Linux follows LD_LIBRARY_PATH and other variables, as pointed out in answer by Gilles.

share|improve this answer
It is nice that you confirm in your second sentence that Gilles answer helps. The first part however doesn't contribute at all to explaining how to tell a.out where the files are, only where the were gotten from if they are already found. All in all this should just be a comment, not an answer. – Anthon Oct 15 '15 at 15:24

In Linux the behavior is explicited in the ld(1) man page

       The linker uses the following search paths to locate required
       shared libraries:

       1.  Any directories specified by -rpath-link options.

       2.  Any directories specified by -rpath options.  The difference
           between -rpath and -rpath-link is that directories specified by
           -rpath options are included in the executable and used at
           runtime, whereas the -rpath-link option is only effective at
           link time. Searching -rpath in this way is only supported by
           native linkers and cross linkers which have been configured
           with the --with-sysroot option.

       3.  On an ELF system, for native linkers, if the -rpath and
           -rpath-link options were not used, search the contents of the
           environment variable "LD_RUN_PATH".

       4.  On SunOS, if the -rpath option was not used, search any
           directories specified using -L options.

       5.  For a native linker, the search the contents of the environment
           variable "LD_LIBRARY_PATH".

       6.  For a native ELF linker, the directories in "DT_RUNPATH" or
           "DT_RPATH" of a shared library are searched for shared
           libraries needed by it. The "DT_RPATH" entries are ignored if
           "DT_RUNPATH" entries exist.

       7.  The default directories, normally /lib and /usr/lib.

       8.  For a native linker on an ELF system, if the file
           /etc/ld.so.conf exists, the list of directories found in that

       If the required shared library is not found, the linker will issue
       a warning and continue with the link.
share|improve this answer
"The default directories, normally /lib and /usr/lib." -> how can I find out if my system is normal? – Thorsten Staerk Dec 6 '14 at 7:30
The question is about runtime and not link time – Talespin_Kit Mar 6 '15 at 10:25

I'm pretty sure the answer here is 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/ld.so.conf, and in the trusted directories (/lib and /usr/lib). The cache is used by the run-time linker, ld.so or ld-linux.so. ldconfig checks the header and filenames of the libraries it encounters when determining which versions should have their links updated.


share|improve this answer

Your Answer


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.