Hi Bruno,

>> Depending on what a package's testsuite looks like, it should
>> ensure that local changes to a shared library (that has previously been
>> installed) will be utilized when linking to an executable, instead of an
>> old installed version.
>> ...
>> I think --test and --check
>> should only be useful for checking and testing of local changes to
>> shared libraries, without the need to install the updated shared
>> library. I have only seen this as an issue with ldconfig on OpenBSD 7.5.
> 
> I am still confused.
> 
> On one hand, when you say "only on OpenBSD", it reminds me of the problem
> that I have seen repeatedly on OpenBSD over the last years (e.g. with
> GNU libunistring, when built without --disable-shared): If I have an
> older version of GNU libunistring installed (in the directory specified
> through --prefix), when building a newer version of GNU libunistring
> (i.e. "make && make check") the "make check" part fails because it
> apparently uses the older version. Whereas "make && make install && make check"
> succeeds. OpenBSD is the only ELF platform on which this 'make install'
> before 'make check' is (or used to be) needed.

I believe this would also be an issue in NetBSD ELF versions, but I have
not verified with libtool's testsuite. The OpenBSD manpage for ldconfig
states that it is the same as the ldconfig in NetBSD 0.9A [1], and the
finish_cmds in libtool are identical for both operating systems.

Performing a make install before make check is limiting, so I would like
to have libtool work around this. I think I understand the issue better
now.

If the shared library cache does not contain paths for an existing
package, the --test and --check options should be useful for verifying
the package is operating properly or for testing different
implementations of shared libraries before finalizing an install, and I
am sure users could find other use cases for it.

However, the --test and --check options would not work for shared
libraries that have existing paths in the shared library cache. I think
this could be fixed if the option(s) are combined with directories to
unconfigure. Users could supply something like this

   'make "LIBTOOLFLAGS=--test=/usr/local/lib" check'

which would execute this

   'ldconfig -U /usr/local/lib'

or a better option could be supplied to libtool to reorder the shared
library cache? The user would pass a list of directories to libtool in
the preferred order, and libtool could do minimal parsing before passing
this list to 'ldconfig -U <dir list>' and 'ldconfig -m <dir list>'. A
reorder option should help ensure that the shared library cache is not
left empty and programs broken.

> On the other hand, during "make && make check", none of the libtool
> modes --mode=finish and --mode=install is used. Automake does not
> generate invocations of "libtool --mode=finish ..." at all, and it
> generates invocations of "libtool --mode=install ..." only as part
> of 'make install', which is typically the last thing I do in a build
> tree. (In the build tree, doing source code modifications and "make"
> will regenerate the libraries using "libtool --mode=link ...", but
> not invoke "libtool --mode=finish ..." nor "libtool --mode=install ...".)
> 
> So, it's not clear to me how your change can have any effect in a
> usual build tree as generated by Automake.

I would agree that this should have no effect on "usual" build trees.
However, it will allow users who do install and later make changes to
shared libraries the ability to avoid ldconfig changing the shared
library cache. I can imagine this may be useful for users
cross-compiling shared libraries, and I know this does resolve the test
failure in OpenBSD for 'Use local version', where old installed
libraries were linked to the executable instead of the intended local
versions.

[1] https://man.openbsd.org/OpenBSD-7.5/ldconfig

-- 
Ileana Dumitrescu

GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354