On Fri, Dec 6, 2013 at 8:56 AM, Richard Crozier <r.croz...@ed.ac.uk> 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.