On 09/11/2024 17:17, Ileana Dumitrescu wrote: > 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