1:38 p.m.
[adding libvir-list, for some cross-compiling development hints]
On 09/17/2013 11:57 AM, Fernando Lozano wrote:
Yes, the libvirt comes grom 0.10.2. I'm running the latest
windows
binaries provided by spice-space.org:
C:\Program Files\VirtViewer\bin>virsh -V
Virsh command line tool of libvirt 0.10.2
Can someone from the Spice community chime in? Why is spice-space.org
shipping a Fedora 18 build of libvirt (0.10.2.x) rather than Fedora 19
(1.0.5.x)? Who does the builds, and how often are they updated?
> Process Monitor is only useful if you make system calls; but
libvirt is
> choking even before attempting the system calls because mingw is just
> such a hostile programming environment to programs that assume POSIX.
That's precisely mingw advantage over cigwin: mingw binaries are native
windows binaries, using native windows semantics, not unix emulation.
They provide a better experience for windows users. Welcome to the
wonderful world of cross-platform developent! ;-)
Actually, on my personal to-do list is to get a build of virsh working
and available from cygwin.com, rather than requiring people to
self-build it for cygwin. And since cygwin supports cross-compilation
to mingw, just as Fedora does, but with the added advantage of also
being able to run mingw binaries without having to worry about bugs in
the wine emulation layer, it's actually a bit nicer for getting the best
of both worlds when doing cross-compiling (posix development, native
testing). If I can ever find the free time...
> Gnulib has helped a lot, and often times, it is just a matter of someone
> running under gdb to see where an assumption went wrong to make a quick
> patch to fix an issue. Where it gets tricky is that it is hard to find
> developers willing to do volunteer work on issues for a platform where
> you typically have to pay money before you can even use it. Also, the
> fact that you are using a pre-built version of a relatively old libvirt,
> instead of building your own from the latest sources, makes it hard to
> know what OTHER issues may have been fixed in the meantime (when given a
> choice, developers prefer to debug issues in the latest source, rather
> than trying to figure out which patches to backport to older branches).
I understand that, but I'm trying to be useful as a (windows) tester. If
I could I'd try to help as a developer. cross-compiling is not for the
faint of heart, and learning the first steps require a significant
investment in time. :-(
Is there a how-to I can follow to generate binaries from the latest
sources? I do have Linux expertize, I use fedora on my personal
computer, but as C developer I can only run "configure; make; sudo make
install".
All I've done so far is test cross-compilation from Fedora to mingw (I
haven't tested the resulting binaries, only that the build completes
without error). I suppose I could try to host the just-built binaries
on a site for you to download; let me see what I can figure out.
Meanwhile, I used './autobuild.sh' as my guide; which means I more or
less did:
$ sudo yum install \
mingw64-binutils \
mingw64-cpp \
mingw64-crt \
mingw64-curl \
mingw64-dbus \
mingw64-filesystem \
mingw64-gcc \
mingw64-gcc-c++ \
mingw64-gettext \
mingw64-gmp \
mingw64-gnutls \
mingw64-headers \
mingw64-libgcrypt \
mingw64-libgpg-error \
mingw64-libidn \
mingw64-libssh2 \
mingw64-libtasn1 \
mingw64-libxml2 \
mingw64-nettle \
mingw64-openssl \
mingw64-p11-kit \
mingw64-pkg-config \
mingw64-portablexdr \
mingw64-termcap \
mingw64-wine-gecko \
mingw64-win-iconv \
mingw64-zlib
$ git clone git://libvirt.org/libvirt.git
$ cd libvirt
$ ./autogen.sh --help # see note [1]
$ mkdir build-mingw
$ cd build-mingw
$ ../configure \
PKG_CONFIG_LIBDIR="/usr/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig:/usr/x86_64-w64-mingw32/sys-root/mingw/share/pkgconfig"
\
PKG_CONFIG_PATH="$AUTOBUILD_INSTALL_ROOT/x86_64-w64-mingw32/sys-root/mingw/lib/pkgconfig"
\
CC="x86_64-w64-mingw32-gcc" \
--build=$(uname -m)-w64-linux \
--host=x86_64-w64-mingw32 \
--prefix="$AUTOBUILD_INSTALL_ROOT/x86_64-w64-mingw32/sys-root/mingw" \
--without-libvirtd \
--without-python
$ make
[1] Yeah, we probably ought to have a more convenient way to bootstrap
libvirt.git for VPATH builds without having to rely on the hack that
options unrecognized by ./autogen.sh are passed on to ./configure, and
that ./configure --help is the easiest way to do avoid polluting the
top-level tree in a way that would interfere with VPATH builds. I use a
VPATH build for my mingw cross-compilation in part so I can test both
32-bit and 64-bit binaries in parallel directories.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org