[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 _______________________________________________ Spice-devel mailing list Spice-devel(a)lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel

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

>> 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? > I do builds when releasing new virt-viewer versions, and I use the latest > stable Fedora available at that time. We've not done any virt-viewer > release since F19 came out. > > There's no reason why I couldn't do bug fix re-builds of the installer > though at any time if deemed neccessary. It would be nice to do a bug fix rebuild as soon as 0.10.2.8 is released, as that would pick up the patch for mingw refusing to create sockets, and hopefully get people a lot further at actually being able to use virsh on mingw.

On 09/18/2013 08:19 AM, Fernando Lozano wrote: > Hi, >>>> 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? >>> I do builds when releasing new virt-viewer versions, and I use the latest >>> stable Fedora available at that time. We've not done any virt-viewer >>> release since F19 came out. >>> >>> There's no reason why I couldn't do bug fix re-builds of the installer >>> though at any time if deemed neccessary. >> It would be nice to do a bug fix rebuild as soon as 0.10.2.8 is >> released, as that would pick up the patch for mingw refusing to create >> sockets, and hopefully get people a lot further at actually being able >> to use virsh on mingw. > I got confused by those release numbers: if Fedora has libvirt 1.0.5.x > why should the next windows build use older 0.10.2.8? I though > development were being done only on the latest releases. Since Dan builds from Fedora, he gets whatever version is in the Fedora side that he builds from. Fedora 18 is on the 0.10.2.x series, with 0.10.2.8 due soon; Fedora 19 is on the 1.0.5.x branch, with 1.0.5.6 due soon. Since the original build was from F18 and Dan didn't build anything from F19 yet, it may be faster to do the refresh from Fedora 18 than to figure out whether Fedora 19 is even buildable for mingw. Or, if he builds from the (still-in-beta) Fedora 20, you'd get a build based off of 1.1.2.