Re: Updating the shared library cache automatically using ldconfig

[Gavin Smith]

On Fri, Dec 6, 2013 at 8:56 AM, Richard Crozier <address@hidden> wrote:
> I am seeing the same issue as described in this previous post to the
> automake mailing list:
>
> http://gnu-automake.7480.n7.nabble.com/quot-error-while-loading-shared-libraries-foo-so-0-cannot-open-shared-object-file-No-such-file-or-di-td3970.html
>
> The issue is that my program uses a shared library installed by 'make
> install' at the same time as my program, but the shared library cache is not
> updated, resulting in the error
>
> "error while loading shared libraries: foo.so.0: cannot open shared object
> file: No such file or directory"
>
> when you try to run the program. This can be solved by manually running
> ldconfig or rebooting. Mostly my users do not know to do this, so we get bug
> reports. How can I have ldconfig run if necessary after make install? What
> exactly should I put in my Makefile.am or elsewhere to do this?

Not completely sure but I'll explain my understanding of the situation.

There are two possible places where this could be fixed:
* When the library is installed
* When the program linking against the library is installed

When the library is installed: This is done using libtool in the
makefile. Installing a libtool library under /usr/local/lib (with an
automake-generated Makefile) I get the following message:
---
Libraries have been installed in:
   /usr/local/lib

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
     during execution
   - add LIBDIR to the `LD_RUN_PATH' environment variable
     during linking
   - use the `-Wl,--rpath -Wl,LIBDIR' linker flag
   - have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
---
(This is under Slackware 14.0.) This message is printed by libtool,
but the makefile calling libtool might also do something to facilitate
linking against the library. In either case you can imagine installing
libraries in locations that you *don't* want to find automatically, so
this is probably fine.

When the program is installed: I get the same results at Ralf
Wildenhues in his post
http://gnu-automake.7480.n7.nabble.com/quot-error-while-loading-shared-libraries-foo-so-0-cannot-open-shared-object-file-No-such-file-or-di-td3970.html#a3973.
When /usr/local/lib is not listed in ld.so.conf, libtool adds an rpath
linker flag and the library search path appears in the produced
binary:
$ readelf -d .libs/foo | grep rpath
 0x0000000f (RPATH)                      Library rpath: [/usr/local/lib]
But if /usr/local/lib *is* in ld.so.conf, it doesn't. However, that is
not enough to find the library - ldconfig has to be run. From the
ld-linux.so man page:

 The shared libraries needed by the program are searched for in the fol-
       lowing order:

       o  (ELF only) Using the directories specified in the  DT_RPATH  dynamic
          section  attribute of the binary if present and DT_RUNPATH attribute
          does not exist.  Use of DT_RPATH is deprecated.

       o  Using the environment variable LD_LIBRARY_PATH.  Except if the  exe-
          cutable  is  a  set-user-ID/set-group-ID binary, in which case it is
          ignored.

       o  (ELF only) Using the directories specified in the DT_RUNPATH dynamic
          section attribute of the binary if present.

       o  From  the cache file /etc/ld.so.cache which contains a compiled list
          of candidate libraries previously found  in  the  augmented  library
          path.   If,  however,  the  binary  was  linked with the -z nodeflib
          linker option, libraries in the default library paths  are  skipped.
          Libraries  installed  in hardware capability directories (see below)
          are preferred to other libraries.

       o  In the default path /lib, and then  /usr/lib.   If  the  binary  was
          linked with the -z nodeflib linker option, this step is skipped.

ld-linux.so does not look at /etc/ld.so.conf. This would seem to be a
problem - maybe libtool should use the -Wl,-rpath -Wl,/usr/local/lib
option in both circumstances?

In the meantime, I think you could use the install-exec-hook target to
run ldconfig to update the cache.