tests/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
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
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
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 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
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 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
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 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
© 2016 - 2024 Red Hat, Inc.