I just noticed that on my GNU/Linux system (and on stock Ubuntu 14.04, which is where I first encountered this), I need to run
ldconfig
after installing shared libraries built with libtool. I was confused at first, because libtool itself runs
ldconfig -n $(libdir)
But I guess because this does not update the cache, it doesn't make the library available.
I hadn't noticed this before because normally when I'm building code on my own system, I install it in my home directory, with a suitable setting of LD_LIBRARY_PATH; no ldconfig call is needed.
The libtool manual says:
7. The install 'Makefile' target should warn the package installer to
set the proper environment variables ('LD_LIBRARY_PATH' or
equivalent), or run 'ldconfig'.
But libtool does not warn me that I (may) need to run ldconfig.
In 1997, commit 7f9b4e50 for libtool version 0.6b, the way of running ldconfig was changed from running without "-n" to running with "-n". The ChangeLog entry (I think it is for the same change, though it occurs months later in commit 41ced2149):
+ *
ltconfig.in (finish_cmds): Change back to using `ldconfig -n'.
+ This makes Linux behave like other systems, which is more in line
+ with what libtool needs.
I'm not sure what it means by "what libtool needs" here, but perhaps 20 years later it's worth reconsidering this (and simply removing the -n flag on Linux again)? Or, if it's not possible, at least warn the user that it may be necessary to run ldconfig.
I'm using libtool version 2.4.6, but I can't see that anything has changed in current git in this respect.
--