bug#30402: ldconfig confusion

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.​​

-- 
https://rrt.sc3d.org

_______________________________________________
Bug-libtool mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/bug-libtool