[libvirt] test failure on rawhide
Just noticed this on latest rawhide (Fedora 21): Looks like the bug might not be libvirt's fault (as the assertion failure is not in our source file), but I'm out of time to investigate further today. $ VIR_TEST_DEBUG=1 ./virdrivermoduletest TEST: virdrivermoduletest 1) Test driver "network" ... OK 2) Test driver "storage" ... OK 3) Test driver "nodedev" ... OK 4) Test driver "secret" ... OK 5) Test driver "nwfilter" ... OK 6) Test driver "interface" ... lt-virdrivermoduletest: route/tc.c:973: rtnl_tc_register: Assertion `0' failed. Aborted -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 08/30/2013 11:26 PM, Eric Blake wrote:
Just noticed this on latest rawhide (Fedora 21):
Looks like the bug might not be libvirt's fault (as the assertion failure is not in our source file), but I'm out of time to investigate further today.
$ VIR_TEST_DEBUG=1 ./virdrivermoduletest TEST: virdrivermoduletest 1) Test driver "network" ... OK 2) Test driver "storage" ... OK 3) Test driver "nodedev" ... OK 4) Test driver "secret" ... OK 5) Test driver "nwfilter" ... OK 6) Test driver "interface" ... lt-virdrivermoduletest: route/tc.c:973: rtnl_tc_register: Assertion `0' failed.
During the switch from libnl-1 to libnl-3, a similar (the same?) error meant that version of libnl used for the netcf build didn't match the version used for the libvirt build. That should be a thing of the distant past now though...
On 09/03/2013 05:00 AM, Laine Stump wrote:
On 08/30/2013 11:26 PM, Eric Blake wrote:
Just noticed this on latest rawhide (Fedora 21):
Looks like the bug might not be libvirt's fault (as the assertion failure is not in our source file), but I'm out of time to investigate further today.
$ VIR_TEST_DEBUG=1 ./virdrivermoduletest TEST: virdrivermoduletest 1) Test driver "network" ... OK 2) Test driver "storage" ... OK 3) Test driver "nodedev" ... OK 4) Test driver "secret" ... OK 5) Test driver "nwfilter" ... OK 6) Test driver "interface" ... lt-virdrivermoduletest: route/tc.c:973: rtnl_tc_register: Assertion `0' failed.
During the switch from libnl-1 to libnl-3, a similar (the same?) error meant that version of libnl used for the netcf build didn't match the version used for the libvirt build. That should be a thing of the distant past now though...
This particular rawhide VM of mine has been incrementally updated since at least F15 days, which predates the libnl switch; I also noticed that I had libnl-devel but NOT libnl3-devel installed. I cleaned out the incremental stuff, installed libnl3-devel, and a build from scratch succeeded. So suspicions confirmed, and fixing my environment fixed the problem. But it DOES point out that maybe configure should try harder to die up front if mismatch is detected (ie. the wrong libnl-devel is installed) - I'll uninstall libnl3-devel, and play with it a bit more, before calling this thread done. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Commits 9298bfb and f6c2951 both tried to make it possible to select the correct libnl (1 vs. 3) according to what netcf used, when both libraries are installed. This works to avoid libnl-3 when netcf used libnl-1. But on the converse side, if only libnl-1 development code is installed, while netcf uses libnl-3, then configure happily uses libnl-1 anyways, leading to a test failure: $ VIR_TEST_DEBUG=1 ./virdrivermoduletest TEST: virdrivermoduletest 1) Test driver "network" ... OK 2) Test driver "storage" ... OK 3) Test driver "nodedev" ... OK 4) Test driver "secret" ... OK 5) Test driver "nwfilter" ... OK 6) Test driver "interface" ... lt-virdrivermoduletest: route/tc.c:973: rtnl_tc_register: Assertion `0' failed. Aborted It's much nicer to prevent this at configure time, by requiring that if we know what netcf used, then we want the same libnl version. As before, this can be bypassed by someone who knows what they are doing by setting LIBNL_CFLAGS (perhaps useful to the rare person where the build box has a different version of netcf than the installation box). * configure.ac (LIBNL): If we can prove netcf used libnl-3, then don't let configure succeed with libnl-1. Signed-off-by: Eric Blake <eblake@redhat.com> --- configure.ac | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configure.ac b/configure.ac index f853e03..9950e3e 100644 --- a/configure.ac +++ b/configure.ac @@ -2416,6 +2416,9 @@ if test "$with_linux" = "yes"; then fi done case $libnl_ldd:${LIBNL_CFLAGS+set} in + *libnl-3.so.*:) LIBNL_REQUIRED=3.0 ;; + esac + case $libnl_ldd:${LIBNL_CFLAGS+set} in *libnl.so.1*:) ;; *) PKG_CHECK_MODULES([LIBNL], [libnl-3.0], [ -- 1.8.3.1
ping; I'm debating about pushing this under the build-breaker rule On 09/04/2013 03:19 PM, Eric Blake wrote:
Commits 9298bfb and f6c2951 both tried to make it possible to select the correct libnl (1 vs. 3) according to what netcf used, when both libraries are installed. This works to avoid libnl-3 when netcf used libnl-1. But on the converse side, if only libnl-1 development code is installed, while netcf uses libnl-3, then configure happily uses libnl-1 anyways, leading to a test failure:
$ VIR_TEST_DEBUG=1 ./virdrivermoduletest TEST: virdrivermoduletest 1) Test driver "network" ... OK 2) Test driver "storage" ... OK 3) Test driver "nodedev" ... OK 4) Test driver "secret" ... OK 5) Test driver "nwfilter" ... OK 6) Test driver "interface" ... lt-virdrivermoduletest: route/tc.c:973: rtnl_tc_register: Assertion `0' failed. Aborted
It's much nicer to prevent this at configure time, by requiring that if we know what netcf used, then we want the same libnl version. As before, this can be bypassed by someone who knows what they are doing by setting LIBNL_CFLAGS (perhaps useful to the rare person where the build box has a different version of netcf than the installation box).
* configure.ac (LIBNL): If we can prove netcf used libnl-3, then don't let configure succeed with libnl-1.
Signed-off-by: Eric Blake <eblake@redhat.com> --- configure.ac | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/configure.ac b/configure.ac index f853e03..9950e3e 100644 --- a/configure.ac +++ b/configure.ac @@ -2416,6 +2416,9 @@ if test "$with_linux" = "yes"; then fi done case $libnl_ldd:${LIBNL_CFLAGS+set} in + *libnl-3.so.*:) LIBNL_REQUIRED=3.0 ;; + esac + case $libnl_ldd:${LIBNL_CFLAGS+set} in *libnl.so.1*:) ;; *) PKG_CHECK_MODULES([LIBNL], [libnl-3.0], [
-- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On Tue, Sep 10, 2013 at 11:52:00AM -0600, Eric Blake wrote:
ping; I'm debating about pushing this under the build-breaker rule
On 09/04/2013 03:19 PM, Eric Blake wrote:
Commits 9298bfb and f6c2951 both tried to make it possible to select the correct libnl (1 vs. 3) according to what netcf used, when both libraries are installed. This works to avoid libnl-3 when netcf used libnl-1. But on the converse side, if only libnl-1 development code is installed, while netcf uses libnl-3, then configure happily uses libnl-1 anyways, leading to a test failure:
$ VIR_TEST_DEBUG=1 ./virdrivermoduletest TEST: virdrivermoduletest 1) Test driver "network" ... OK 2) Test driver "storage" ... OK 3) Test driver "nodedev" ... OK 4) Test driver "secret" ... OK 5) Test driver "nwfilter" ... OK 6) Test driver "interface" ... lt-virdrivermoduletest: route/tc.c:973: rtnl_tc_register: Assertion `0' failed. Aborted
It's much nicer to prevent this at configure time, by requiring that if we know what netcf used, then we want the same libnl version. As before, this can be bypassed by someone who knows what they are doing by setting LIBNL_CFLAGS (perhaps useful to the rare person where the build box has a different version of netcf than the installation box).
* configure.ac (LIBNL): If we can prove netcf used libnl-3, then don't let configure succeed with libnl-1.
Signed-off-by: Eric Blake <eblake@redhat.com> --- configure.ac | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/configure.ac b/configure.ac index f853e03..9950e3e 100644 --- a/configure.ac +++ b/configure.ac @@ -2416,6 +2416,9 @@ if test "$with_linux" = "yes"; then fi done case $libnl_ldd:${LIBNL_CFLAGS+set} in + *libnl-3.so.*:) LIBNL_REQUIRED=3.0 ;; + esac + case $libnl_ldd:${LIBNL_CFLAGS+set} in *libnl.so.1*:) ;; *) PKG_CHECK_MODULES([LIBNL], [libnl-3.0], [
ACK Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On 09/11/2013 02:15 AM, Daniel P. Berrange wrote:
On Tue, Sep 10, 2013 at 11:52:00AM -0600, Eric Blake wrote:
ping; I'm debating about pushing this under the build-breaker rule
It's much nicer to prevent this at configure time, by requiring that if we know what netcf used, then we want the same libnl version. As before, this can be bypassed by someone who knows what they are doing by setting LIBNL_CFLAGS (perhaps useful to the rare person where the build box has a different version of netcf than the installation box).
* configure.ac (LIBNL): If we can prove netcf used libnl-3, then don't let configure succeed with libnl-1.
ACK
Thanks; pushed. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
participants (3)
-
Daniel P. Berrange -
Eric Blake -
Laine Stump