mirror of https://gitee.com/openkylin/libvirt.git
![]() Recent spec file changes ensure that in distro situations, netcf and libvirt will link against the same libnl in order to avoid dumping core. But for every-day development, if you use F17 and have the libnl3-devel headers available, libvirt was blindly linking against libnl3 even though F17 netcf still links against libnl1, making testing a self-built binary on F17 impossible. By making configure a little bit smarter, we can avoid this situation - we merely skip the probe of libnl-3 if we can prove that netcf is still using libnl-1. I intentionally wrote the test so that we still favor libnl-3 if netcf is not installed or if we couldn't use ldd to determine things. Defaults being what they are, someone will invariably complain that our smarts were wrong. Never fear - in that case, just run ./configure LIBNL_CFLAGS=..., where the fact that you set LIBNL_CFLAGS (even to the empty string) will go back to probing for libnl-3, regardless of netcf's choice. * configure.ac (LIBNL): Don't probe libnl3 if netcf doesn't use it. |
||
---|---|---|
.gnulib@440a1dbe52 | ||
build-aux | ||
daemon | ||
docs | ||
examples | ||
gnulib | ||
include | ||
m4 | ||
po | ||
python | ||
src | ||
tests | ||
tools | ||
.dir-locals.el | ||
.gitignore | ||
.gitmodules | ||
.mailmap | ||
AUTHORS | ||
COPYING.LIB | ||
ChangeLog-old | ||
HACKING | ||
Makefile.am | ||
Makefile.nonreentrant | ||
README | ||
README-hacking | ||
TODO | ||
autobuild.sh | ||
autogen.sh | ||
bootstrap | ||
bootstrap.conf | ||
cfg.mk | ||
configure.ac | ||
libvirt.pc.in | ||
libvirt.spec.in | ||
mingw-libvirt.spec.in |
README
LibVirt : simple API for virtualization Libvirt is a C toolkit to interact with the virtualization capabilities of recent versions of Linux (and other OSes). It is free software available under the GNU Lesser General Public License. Virtualization of the Linux Operating System means the ability to run multiple instances of Operating Systems concurrently on a single hardware system where the basic resources are driven by a Linux instance. The library aim at providing long term stable C API initially for the Xen paravirtualization but should be able to integrate other virtualization mechanisms if needed. Daniel Veillard <veillard@redhat.com>