]> xenbits.xensource.com Git - libvirt.git/commit
build: require libnl-3 if netcf uses it
authorEric Blake <eblake@redhat.com>
Wed, 4 Sep 2013 21:12:48 +0000 (15:12 -0600)
committerEric Blake <eblake@redhat.com>
Wed, 11 Sep 2013 20:10:33 +0000 (14:10 -0600)
commitcf83adfb7d71b739ac330fff7c8c1ab7dddeed17
tree02878dda9fb56bb7c9c8591433e192c280f3e2a6
parent468f684e84a6f2dedc60f2a8ed13ba9fbd3df459
build: require libnl-3 if netcf uses it

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