Where do executables look for shared objects at runtime?

I recognize just how to specify include shared things at linking/compile time. Nonetheless, I still ask yourself just how do executables seek the common object (*.so collections) at implementation time.

As an example, my application a.out calls features specified in the lib.so collection. After compiling, I relocate lib.so to a new directory site in my $HOME.

Just how can I inform a.out to go seek it there?

171
unix
2022-06-05 01:21:57
Source Share
Answers: 3

The shared library HOWTO clarifies a lot of the devices entailed, and also the dynamic loader manual enters into even more information. Each unix version has its very own means, yet the majority of make use of the very same executable layout (ELF) and also have comparable dynamic linkers (stemmed from Solaris). Listed below I'll sum up the usual actions with a concentrate on Linux ; examine your system is guidebooks for the full tale.

(Terminology note : the component of the system that lots shared collections is usually called "dynamic linker", yet occasionally "dynamic loader" to be extra specific. "Dynamic linker" can additionally suggest the device that creates guidelines for the vibrant loader when compiling a program, or the mix of the compile - time device and also the run - time loader. In this solution, "linker" describes the run - time component.)

In short, when it is seeking a vibrant collection (.so documents) the linker attempts :

  • directory sites detailed in the LD_LIBRARY_PATH setting variable (DYLD_LIBRARY_PATH on OSX) ;
  • directory sites detailed in the executable is rpath ;
  • directory sites on the system search path, which (on Linux at the very least) contains the access in /etc/ld.so.conf plus /lib and also /usr/lib .

The rpath is saved in the executable (it is the DT_RPATH or DT_RUNPATH vibrant feature). It can have outright courses or courses beginning with $ORIGIN to show a path about the area of the executable (as an example if the executable remains in /opt/myapp/bin and also its rpath is $ORIGIN/../lib:$ORIGIN/../plugins after that the vibrant linker will certainly search in /opt/myapp/lib and also /opt/myapp/plugins). The rpath is generally established when the executable is assembled, with the -rpath alternative to ld, yet you can transform it after that with chrpath.

In the circumstance you define, if you are the programmer or packager of the application and also plan for it to be mounted in a …/bin, …/lib framework, after that relate to -rpath='$ORIGIN/../lib'. If you are mounting a pre - constructed binary on your system, either placed the collection in a directory site on the search path (/usr/local/lib if you are the system manager, or else a directory site that you include in $LD_LIBRARY_PATH), or attempt chrpath.

169
2022-06-05 02:32:12
Source

I'm rather sure the solution below is ldconfig.

ldconfig develops the essential web links and also cache to one of the most current common collections located in the directory sites defined on the command line, in the documents/ etc/ld. so.conf, and also in the relied on directory sites (/ lib and also/ usr/lib). The cache is made use of by the run - time linker, ld.so or ld - linux.so. ldconfig checks the header and also filenames of the collections it runs into when establishing which variations need to have their web links upgraded.

http://linux.die.net/man/8/ldconfig

6
2022-06-05 01:42:27
Source

In Linux the actions is explicited in the ld(1) male web 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
           file.

       If the required shared library is not found, the linker will issue
       a warning and continue with the link.
23
2022-06-05 01:42:03
Source

Related questions