mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2024-11-03 11:51:11 +00:00
2621d48f00
This deletes all trace of gnulib from libvirt. We still have the keycodemapdb submodule to deal with. The simple solution taken was to update it when running autogen.sh. Previously gnulib could auto-trigger refresh when running 'make' too. We could figure out a solution for this, but with the pending meson rewrite it isn't worth worrying about, given how infrequently keycodemapdb changes. Reviewed-by: Pavel Hrdina <phrdina@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
118 lines
3.3 KiB
XML
118 lines
3.3 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE html>
|
|
<html xmlns="http://www.w3.org/1999/xhtml">
|
|
<body>
|
|
<h1><a id="installation">libvirt Installation</a></h1>
|
|
|
|
<ul id="toc"></ul>
|
|
|
|
<h2><a id="compiling">Compiling a release tarball</a></h2>
|
|
|
|
<p>
|
|
libvirt uses the standard configure/make/install steps and mandates
|
|
that the build directory is different that the source directory:
|
|
</p>
|
|
|
|
<pre>
|
|
$ xz -c libvirt-x.x.x.tar.xz | tar xvf -
|
|
$ cd libvirt-x.x.x
|
|
$ mkdir build && cd build
|
|
$ ../configure</pre>
|
|
|
|
<p>
|
|
The <i>configure</i> script can be given options to change its default
|
|
behaviour.
|
|
</p>
|
|
|
|
<p>
|
|
To get the complete list of the options it can take, pass it the
|
|
<i>--help</i> option like this:
|
|
</p>
|
|
|
|
<pre>
|
|
$ ../configure <i>--help</i></pre>
|
|
|
|
<p>
|
|
When you have determined which options you want to use (if any),
|
|
continue the process.
|
|
</p>
|
|
|
|
<p>
|
|
Note the use of <b>sudo</b> with the <i>make install</i> 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.
|
|
</p>
|
|
|
|
<p>
|
|
If you are installing to a location that your user <i>does</i> have write
|
|
access to, then you can instead run the <i>make install</i> command
|
|
without putting <b>sudo</b> before it.
|
|
</p>
|
|
|
|
<pre>
|
|
$ ../configure <i>[possible options]</i>
|
|
$ make
|
|
$ <b>sudo</b> <i>make install</i></pre>
|
|
|
|
<p>
|
|
At this point you <b>may</b> have to run ldconfig or a similar utility
|
|
to update your list of installed shared libs.
|
|
</p>
|
|
|
|
<h2><a id="building">Building from a GIT checkout</a></h2>
|
|
|
|
<p>
|
|
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 <code>autogen.sh</code> command. By default when
|
|
the <code>configure</code> 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.
|
|
</p>
|
|
|
|
<p>To build & install libvirt to your home
|
|
directory the following commands can be run:
|
|
</p>
|
|
|
|
<pre>
|
|
$ ./autogen.sh --prefix=$HOME/usr
|
|
$ make
|
|
$ <b>sudo</b> make install</pre>
|
|
|
|
<p>
|
|
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
|
|
</p>
|
|
|
|
<pre>
|
|
$ ./autogen.sh --system
|
|
$ make
|
|
</pre>
|
|
|
|
<p>
|
|
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
|
|
</p>
|
|
|
|
<pre>
|
|
$ su -
|
|
# service libvirtd stop (or systemctl stop libvirtd.service)
|
|
# /home/to/your/checkout/src/libvirtd
|
|
</pre>
|
|
|
|
<p>
|
|
It is also possible to run virsh directly from the source tree
|
|
using the ./run script (which sets some environment variables):
|
|
</p>
|
|
|
|
<pre>
|
|
$ ./run ./tools/virsh ....
|
|
</pre>
|
|
</body>
|
|
</html>
|