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 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
libtool (use with autotest)
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
Re: libtool (use with autotest)
On 2023-07-24, Simon Sobisch wrote:
>
> 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?
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 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
> 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.
Hope that helps,
Nick
