GNU bug report logs - #70982
test suite failures on OpenBSD

Previous Next

Full log

Message #25 received at 70982-done <at> debbugs.gnu.org (full text, mbox):

From: Ileana Dumitrescu <ileanadumitrescu95 <at> gmail.com>
To: Bruno Haible <bruno <at> clisp.org>, 70982-done <at> debbugs.gnu.org
Subject: Re: bug#70982: test suite failures on OpenBSD
Date: Tue, 12 Nov 2024 20:58:07 +0200

[Message part 1 (text/plain, inline)]

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

I have implemented a separate option '--reorder-cache=DIRS' for OpenBSD
users to reorder the shared library cache [2]. If verified that NetBSD
ELF versions have this issue also, I will update the documentation and
case statements.

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

The 'Use local version' test should work without the use of LIBTOOLFLAGS
now, since it is using '--reorder-cache=DIRS'. I think '--test' and/or
'--check' are still useful options for users of OpenBSD, and it should
be clearer on how to use them with the new option and documentation
updates.

I would like to have these options available in the next stable release,
which I have committed to doing before the end of next week. If there
are any more issues that you observe, I am happy to improve these
features.

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

[2] 
https://git.savannah.gnu.org/cgit/libtool.git/commit/?h=development&id=0a1e894220521e5955371eea5408fd6f7a5149c1

-- 
Ileana Dumitrescu

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

[OpenPGP_0x6570EA01146F7354.asc (application/pgp-keys, attachment)]

[OpenPGP_signature.asc (application/pgp-signature, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.