Re: libtool (use with autotest)

Thank you for the feedback, I may need to make this clearer....

Am 24.07.2023 um 22:01 schrieb Nick Bowler:
> On 2023-07-24, Simon Sobisch <[email protected]> wrote:
>>
>> [...]
>>
>> 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?
> 
> The normal way is to set AUTOTEST_PATH so that all the programs under
> test are in it.  When using Autoconf, this is usually done via the
> the second argument to the AC_CONFIG_TESTDIR macro.

I didn't know of either of those, this is very promising, thanks!
So I'd only set it for `make check` (to the directories containing the 
wrappers of the binary programs - so "bin" and "bin2" in the example 
above), but for `make installcheck` set it to the bindir (=installed 
location) where the non-wrappers are.

> I must be missing some context here, as I'm afraid I don't understand
> what the problem is.  To use valgrind in an Autotest test suite together
> with libtool, I would do something like this (untested):
> 
>    m4_divert_text([PREPARE_TESTS], [: ${LIBTOOL="$SHELL $builddir/libtool"}
>    ])
> 
>    AT_TESTED([my_program])
> 
>    AT_SETUP([my test w/ valgrind])
> 
>    AT_CHECK([$LIBTOOL --mode=execute valgrind my_program], [...])
>    [...]
> 
>    AT_CLEANUP

That's interesting and would be doable.

The outstanding question is: How to handle the library in "runtime"?
Currently the compiler uses "-lrun -L/abs/build/runtime", which allows 
not-isntalled executables (only created within the testsuite) to be created.

Executing those programs can't be done "out-of-the-box", as they miss 
the runtime path to librun (currently under runtime/.libs/librun) and 
instead take the already (older) installed one.

How to execute those?
The _bad workaround_ we use is to add that path to LD_LIBRAR_PATH (for 
GNU/Linux), PATH (dos/win32) along with DYLD_LIBRARY_PATH, SHLIB_PATH, 
LIBPATH; which seems to not be the idea behind libtool...

So how would I execute a test program (=not libtoolized), allowing it to 
find librun?
People told us that it would be good to add its path via RPATH to all 
compiled test programs (but setting that is not portable to all 
environments either, not even those that use gcc...).
And using rpath in general tends to get problematic because if this is 
set "directly" in Makefile.am, then the non-installed will already look 
in the installdir (libtool may adjust that, not sure).

>> Bonus:
>> How to do this in a way that allows `make installcheck`?
> 
> If you use AUTOTEST_PATH to locate the programs under test, I wouldn't
> expect there to be any particular problem with installcheck.

Now that I know of this: me neither - having it set to either the 
program directories that contain the wrapper or to bindir, depending on 
the check target.

But again we have the issue about the library path of the installed 
library (may be reasonable to expect that to be setup in the system, not 
sure).

> Hope that helps,
>    Nick

A bit - thank you for the fast answer, I think that this can be actually 
solved for our project "soon".

Simon