[virt-tools-list] [Spice-devel] More on virt-viewer for windows

Tue Sep 17 18:48:33 UTC 2013

----- Original Message -----
> [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?

They are actually built by Daniel, and hosted on virt-manager.org, with link in http://virt-manager.org/download/

(note, I think virt-tools.org would be better though)

It's usually built with current fedora, when doing a new virt-viewer release.

> >> 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

I would yum-builddep mingw-libvirt

> $ 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

This is also quite convenient, if you are not aware of it:

mingw32-configure --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
> 
> 
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
> 