10:01 a.m.
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
12:11 p.m.
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
12:46 p.m.
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
8:17 a.m.
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
2396
days inactive
2397
days old
3 comments
3 participants
participants (3)
-
Andrea Bolognani -
Eric Blake -
Maciej Wolny