libtool (use with autotest)

Simon Sobisch <[email protected]> Mon, 24 Jul 2023 21:02:29 +0200
Newsgroups gmane.comp.sysutils.autoconf.general,gmane.comp.gnu.libtool.general
Message-ID <[email protected]>
I hope to possibly get an answer by moving this question to the 
appropriate lists :-)
For more context I provide the original responses to this topic.

Am 06.07.2023 um 14:55 schrieb Jose E. Marchesi:
>
>> On 2023-07-03 17:16:59 +0200, Bruno Haible wrote:
>>> Someone wrote:
>>>> Without relinking at install time, I don't see how tests can
>>>> reliably load the just-built library from the sources (objdir
>>>> really) rather than loading the installed library.  Unless
>>>> perhaps there is a belief that LD_LIBARY_PATH is reliable and
>>>> supercedes, and there are wrappers
>>>
>>> Yes, on all ELF systems, libtool creates wrappers that set
>>> LD_LIBRARY_PATH, for all programs that link to shared libraries in
>>> the build dir.
>>
>> But wrappers have drawbacks: they make the use of gdb or valgrind
>> less convenient.
>
> Just a tiny bit less convenient:
>
> $ libtool --mode=execute gdb ./prog
> $ libtool --mode=execute valgrind ./prog

Just to recheck:

When using both autotest (autoconf) generated testsuites and libtool,
then how should we handle the following, given that we generate

bin/runner
bin2/compiler
runtime/librun

* specify binaries to test AT_TESTED
They are not in PATH, so should we add the libtool generated binaries'
path to PATH for `make check` before the testsuite is executed?
Should we run `make check`

* execute the binaries in the testsuite within AT_CHECK (possibly using
the wrapper's full path [which would be troublesome for all output of 
argv[0] that the program may do]?)

* execute other binaries within AT_CHECK that are linked to librun

Bonus:
How to do this in a way that allows `make installcheck`?

Thanks for any insights,
Simon