libtool (use with autotest)

[Simon Sobisch]

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