[libvirt] [PATCH] tests/Makefile.am: use LIBTOOL variable instead of hardcoded name
This caused an error on Debian, where the tool is called libtoolize, not libtool. --- tests/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/Makefile.am b/tests/Makefile.am index 7b93fbde6..05db6b119 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -487,7 +487,7 @@ VALGRIND = valgrind --quiet --leak-check=full --trace-children=yes \ --trace-children-skip="*/tools/virsh","*/tests/commandhelper" \ --suppressions=$(srcdir)/.valgrind.supp valgrind: - $(MAKE) check VG="libtool --mode=execute $(VALGRIND)" + $(MAKE) check VG="$(LIBTOOL) --mode=execute $(VALGRIND)" sockettest_SOURCES = \ sockettest.c \ -- 2.11.0
On Mon, 2018-04-30 at 16:01 +0100, Maciej Wolny wrote:
This caused an error on Debian, where the tool is called libtoolize, not libtool.
Can you please share the specific error message? libtool and libtoolize are two different programs: the latter is used to setup a project for using the former, which in turn is called instead of the compiler and linker during build. AFAICT, that's both the upstream and downstream behavior, regardless of distribution.
- $(MAKE) check VG="libtool --mode=execute $(VALGRIND)" + $(MAKE) check VG="$(LIBTOOL) --mode=execute $(VALGRIND)"
What we might want to do here is call $(top_srcdir)/libtool instead of plain libtool, so that we run the local copy installed by libtoolize rather than the vendor-provided one, and we don't require the user to install libtool at all when building from a release archive rather than a git checkout. -- Andrea Bolognani / Red Hat / Virtualization
On 30/04/18 18:11, Andrea Bolognani wrote:
- $(MAKE) check VG="libtool --mode=execute $(VALGRIND)" + $(MAKE) check VG="$(LIBTOOL) --mode=execute $(VALGRIND)" What we might want to do here is call $(top_srcdir)/libtool instead of plain libtool, so that we run the local copy installed by libtoolize rather than the vendor-provided one, and we don't require the user to install libtool at all when building from a release archive rather than a git checkout.
$(LIBTOOL) is set to $(top_srcdir)/libtool in the generated Makefile. My understanding was that automake copies the rule I modified verbatim into the generated Makefile, but maybe I misunderstood. If so, I'll post another patch as you suggested. Here's the error message: /bin/bash: line 2: libtool: command not found
On 04/30/2018 10:01 AM, Maciej Wolny wrote:
This caused an error on Debian, where the tool is called libtoolize, not libtool.
The commit message is incorrect (we are not trying to call the installed libtoolize program, but the just-built libtool script that resides in our tree), but the fix itself is correct.
--- tests/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/Makefile.am b/tests/Makefile.am index 7b93fbde6..05db6b119 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -487,7 +487,7 @@ VALGRIND = valgrind --quiet --leak-check=full --trace-children=yes \ --trace-children-skip="*/tools/virsh","*/tests/commandhelper" \ --suppressions=$(srcdir)/.valgrind.supp valgrind: - $(MAKE) check VG="libtool --mode=execute $(VALGRIND)" + $(MAKE) check VG="$(LIBTOOL) --mode=execute $(VALGRIND)"
sockettest_SOURCES = \ sockettest.c \
-- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
participants (3)
-
Andrea Bolognani -
Eric Blake -
Maciej Wolny