libvirt uses the standard configure/make/install steps and mandates that the build directory is different that the source directory:
$ xz -c libvirt-x.x.x.tar.xz | tar xvf - $ cd libvirt-x.x.x $ mkdir build && cd build $ ../configure
The configure script can be given options to change its default behaviour.
To get the complete list of the options it can take, pass it the --help option like this:
$ ../configure --help
When you have determined which options you want to use (if any), continue the process.
Note the use of sudo with the make install command below. Using sudo is only required when installing to a location your user does not have write access to. Installing to a system location is a good example of this.
If you are installing to a location that your user does have write access to, then you can instead run the make install command without putting sudo before it.
$ ../configure [possible options] $ make $ sudo make install
At this point you may have to run ldconfig or a similar utility to update your list of installed shared libs.
The libvirt build process uses GNU autotools, so after obtaining a
checkout it is necessary to generate the configure script and Makefile.in
templates using the autogen.sh command. By default when
the configure script is run from within a GIT checkout, it
will turn on -Werror for builds. This can be disabled with
--disable-werror, but this is not recommended.
Libvirt takes advantage of
the gnulib
project to provide portability to a number of platforms. This
is normally done dynamically via a git submodule in
the .gnulib subdirectory, which is auto-updated as
needed when you do incremental builds. Setting the environment
variable GNULIB_SRCDIR to a local directory
containing a git checkout of gnulib will let you reduce local
disk space requirements and network download time, regardless of
which actual commit you have in that reference directory.
However, if you are developing on a platform where git is not available, or are behind a firewall that does not allow for git to easily obtain the gnulib submodule, it is possible to instead use a static mode of operation where you are then responsible for updating the git submodule yourself. In this mode, you must track the exact gnulib commit needed by libvirt (usually not the latest gnulib.git) via alternative means, such as a shared NFS drive or manual download, and run this any time libvirt.git updates the commit stored in the .gnulib submodule:
$ GNULIB_SRCDIR=/path/to/gnulib ./autogen.sh --no-git
To build & install libvirt to your home directory the following commands can be run:
$ ./autogen.sh --prefix=$HOME/usr $ make $ sudo make install
Be aware though, that binaries built with a custom prefix will not interoperate with OS vendor provided binaries, since the UNIX socket paths will all be different. To produce a build that is compatible with normal OS vendor prefixes, use
$ ./autogen.sh --system
$ make
When doing this for day-to-day development purposes, it is recommended not to install over the OS vendor provided binaries. Instead simply run libvirt directly from the source tree. For example to run a privileged libvirtd instance
$ su -
# service libvirtd stop (or systemctl stop libvirtd.service)
# /home/to/your/checkout/src/libvirtd
It is also possible to run virsh directly from the source tree using the ./run script (which sets some environment variables):
$ ./run ./tools/virsh ....