Re: [libvirt] [virt-tools-list] [Spice-devel] More on virt-viewer for windows
[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
----- 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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
On Tue, Sep 17, 2013 at 12:38:03PM -0600, Eric Blake wrote:
[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?
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. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On 09/18/2013 01:43 AM, Daniel P. Berrange wrote:
On Tue, Sep 17, 2013 at 12:38:03PM -0600, Eric Blake wrote:
[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?
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. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
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.
[]s, Fernando Lozano
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. Development happens upstream, but we DO backport patches to the stable release branches that Fedora uses. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On Wed, Sep 18, 2013 at 08:24:26AM -0600, Eric Blake wrote:
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.
We have a new virt-viewer release we want to get out soon. I'll be building on F19 when i do that. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
Any chance of getting an updated virt-viewer rpm for f18? CC --- Sent from my Galaxy Nexus On 18 Sep 2013 22:28, "Daniel P. Berrange" <berrange@redhat.com> wrote:
On Wed, Sep 18, 2013 at 08:24:26AM -0600, Eric Blake wrote:
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.
We have a new virt-viewer release we want to get out soon. I'll be building on F19 when i do that.
Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/:| |: http://libvirt.org -o- http://virt-manager.org:| |: http://autobuild.org -o- http://search.cpan.org/~danberr/:| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc:|
_______________________________________________ virt-tools-list mailing list virt-tools-list@redhat.com https://www.redhat.com/mailman/listinfo/virt-tools-list
participants (6)
-
Colin Coe -
Daniel P. Berrange -
Eric Blake -
Fernando Lozano -
Laine Stump -
Marc-André Lureau