----- 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@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/spice-devel > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list