On Fri, 9 Feb 2018, Reuben Thomas wrote:
>
> 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.​​

This feels like a big dangerous change to me, especially since the 
current mode of operation has been in place for 20 years.  Should 
installing a package result in refreshing the configuration for the 
whole system, causing changes unrelated to the package?

The installation prefix used is important since it might be into a 
directory already configured via /etc/ld.so.conf or it might be some 
directory that ldconfig does not know about.

I see that Ubuntu provides special handling for /usr/local via 
/etc/ld.so.conf.d/libc.conf:

% cat /etc/ld.so.conf
include /etc/ld.so.conf.d/*.conf

% cat /etc/ld.so.conf.d/libc.conf
# libc default configuration
/usr/local/lib

If one installs into a prefix that ldconfig does not already know 
about, then it seems that additional ldconfig configuration should be 
required in order for shared libraries installed there to work 
correctly.

Bob
-- 
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/