mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2024-11-03 11:51:11 +00:00
1e503ee534
Based on a report by Chandrashekar Shastri, at https://bugzilla.redhat.com/show_bug.cgi?id=979360 On systems where git cannot access the outside world, a developer can instead arrange to get a copy of gnulib at the right commit via side channels (such as NFS share drives), set GNULIB_SRCDIR, then use ./autogen.sh --no-git. In this setup, we will now avoid direct use of git. Of course, this means no automatic gnulib updates when libvirt.git updates its submodule, but it is expected that any developer in such a situation is already prepared to deal with the fallout. * .gnulib: Update to latest, for bootstrap. * bootstrap: Synchronize from gnulib. * autogen.sh (no_git): Avoid git when requested. * cfg.mk (_update_required): Skip automatic rerun of bootstrap if we can't use git. * docs/compiling.html.in: Document this setup. * docs/hacking.html.in: Mention this. * HACKING: Regenerate. Signed-off-by: Eric Blake <eblake@redhat.com>
141 lines
4.7 KiB
XML
141 lines
4.7 KiB
XML
<?xml version="1.0" encoding="UTF-8"?>
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
|
<html xmlns="http://www.w3.org/1999/xhtml">
|
|
<body>
|
|
<h1><a name="installation">libvirt Installation</a></h1>
|
|
|
|
<ul id="toc"></ul>
|
|
|
|
<h2><a name="compiling">Compiling a release tarball</a></h2>
|
|
|
|
<p>
|
|
libvirt uses the standard configure/make/install steps:
|
|
</p>
|
|
|
|
<pre>
|
|
$ gunzip -c libvirt-x.x.x.tar.gz | tar xvf -
|
|
$ cd libvirt-x.x.x
|
|
$ ./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 name="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>
|
|
Libvirt takes advantage of
|
|
the <a href="http://www.gnu.org/software/gnulib/">gnulib</a>
|
|
project to provide portability to a number of platforms. This
|
|
is normally done dynamically via a git submodule in
|
|
the <code>.gnulib</code> subdirectory, which is auto-updated as
|
|
needed when you do incremental builds. Setting the environment
|
|
variable <code>GNULIB_SRCDIR</code> 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.
|
|
</p>
|
|
<p>
|
|
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:</p>
|
|
<pre>
|
|
$ GNULIB_SRCDIR=/path/to/gnulib ./autogen.sh --no-git
|
|
</pre>
|
|
|
|
<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/daemon/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>
|