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