Re: [Qemu-devel] Problems with native Mingw-w64 build
Am 31.03.2017 um 19:08 schrieb Mark Cave-Ayland: On 28/03/17 16:16, Thomas Huth wrote: We've already got a page with instructions for building with MingW: http://wiki.qemu-project.org/Hosts/W32 So that might be a good place to add your experience with MSYS, I guess? Done. See http://wiki.qemu-project.org/Hosts/W32#Native_builds_with_MSYS2 for details of how to build on W64 with MSYS2. ATB, Mark. Great, thank you. I added some notes on Intel HAXM, too. Stefan
Re: [Qemu-devel] Problems with native Mingw-w64 build
On 28/03/17 16:16, Thomas Huth wrote: > On 28.03.2017 09:25, Mark Cave-Ayland wrote: > [...] >> I ended up starting again from scratch last night and trying the build >> with MSYS2 instead. MSYS2 has really improved since I last looked at it >> a couple of years back, and I was able to get a working build >> environment all set and working without any issues, i.e. set up the >> build environment, run configure, make and make install. >> >> I did make a few notes during installation so if people think it's >> useful I can work through them again and come up with something suitable >> for the wiki. > > We've already got a page with instructions for building with MingW: > > http://wiki.qemu-project.org/Hosts/W32 > > So that might be a good place to add your experience with MSYS, I guess? Done. See http://wiki.qemu-project.org/Hosts/W32#Native_builds_with_MSYS2 for details of how to build on W64 with MSYS2. ATB, Mark.
Re: [Qemu-devel] Problems with native Mingw-w64 build
On 28.03.2017 09:25, Mark Cave-Ayland wrote: [...] > I ended up starting again from scratch last night and trying the build > with MSYS2 instead. MSYS2 has really improved since I last looked at it > a couple of years back, and I was able to get a working build > environment all set and working without any issues, i.e. set up the > build environment, run configure, make and make install. > > I did make a few notes during installation so if people think it's > useful I can work through them again and come up with something suitable > for the wiki. We've already got a page with instructions for building with MingW: http://wiki.qemu-project.org/Hosts/W32 So that might be a good place to add your experience with MSYS, I guess? Thomas
Re: [Qemu-devel] Problems with native Mingw-w64 build
On 27/03/17 21:19, Stefan Weil wrote: > Am 27.03.2017 um 07:48 schrieb Mark Cave-Ayland: >> Right, I see cygwin has a much newer version of glib available which >> explains how the builds are produced. >> >> What was the exact issue with global symbols which prevents the >> pre-built Win64 binaries from glib > 2.22 being used? Or is that >> information now obsolete? > > I remember a problem caused by a change in Mingw gcc name mangling, > maybe that's what you a referring to. That does not apply to the > libraries distributed with Cygwin. > > There is a new problem with cross compiling on Cygwin caused by latest > changes in configure. I have just sent a patch to fix that regression. I ended up starting again from scratch last night and trying the build with MSYS2 instead. MSYS2 has really improved since I last looked at it a couple of years back, and I was able to get a working build environment all set and working without any issues, i.e. set up the build environment, run configure, make and make install. I did make a few notes during installation so if people think it's useful I can work through them again and come up with something suitable for the wiki. ATB, Mark.
Re: [Qemu-devel] Problems with native Mingw-w64 build
Am 27.03.2017 um 07:48 schrieb Mark Cave-Ayland: Right, I see cygwin has a much newer version of glib available which explains how the builds are produced. What was the exact issue with global symbols which prevents the pre-built Win64 binaries from glib > 2.22 being used? Or is that information now obsolete? I remember a problem caused by a change in Mingw gcc name mangling, maybe that's what you a referring to. That does not apply to the libraries distributed with Cygwin. There is a new problem with cross compiling on Cygwin caused by latest changes in configure. I have just sent a patch to fix that regression. Stefan
Re: [Qemu-devel] Problems with native Mingw-w64 build
On 26/03/17 20:54, Stefan Weil wrote: > Am 26.03.2017 um 14:57 schrieb Peter Maydell: >> On 26 March 2017 at 11:30, Mark Cave-Ayland >>wrote: >>> In order to do some testing on a Windows box, I've spent a bit of time >>> this weekend setting up a mingw-w64 build environment on Windows 10 >>> using http://wiki.qemu-project.org/Hosts/W32 as a guideline. >> >> I think most people prefer to use the cross-compile. >> Stefan might do native compiles. > > All installers on https://qemu.weilnetz.de/ are cross built > on Debian GNU Linux, but from time to time I also build on > Windows. > > Setting up a build environment based on Cygwin works pretty > well because Cygwin includes most needed packages to cross > compile for Mingw-w64, both for 32 bit (mingw64-i686-*) > and 64 bit (mingw64-x86_64-*), see > https://cygwin.com/cgi-bin2/package-grep.cgi?grep=mingw64-=x86_64. > > I also use the Cygwin packages on Debian GNU Linux, > because Debian includes cross tools (compiler, linker) > for Mingw-w64, but nearly no libraries. Right, I see cygwin has a much newer version of glib available which explains how the builds are produced. What was the exact issue with global symbols which prevents the pre-built Win64 binaries from glib > 2.22 being used? Or is that information now obsolete? ATB, Mark.
Re: [Qemu-devel] Problems with native Mingw-w64 build
Am 26.03.2017 um 14:57 schrieb Peter Maydell: On 26 March 2017 at 11:30, Mark Cave-Aylandwrote: In order to do some testing on a Windows box, I've spent a bit of time this weekend setting up a mingw-w64 build environment on Windows 10 using http://wiki.qemu-project.org/Hosts/W32 as a guideline. I think most people prefer to use the cross-compile. Stefan might do native compiles. All installers on https://qemu.weilnetz.de/ are cross built on Debian GNU Linux, but from time to time I also build on Windows. Setting up a build environment based on Cygwin works pretty well because Cygwin includes most needed packages to cross compile for Mingw-w64, both for 32 bit (mingw64-i686-*) and 64 bit (mingw64-x86_64-*), see https://cygwin.com/cgi-bin2/package-grep.cgi?grep=mingw64-=x86_64. I also use the Cygwin packages on Debian GNU Linux, because Debian includes cross tools (compiler, linker) for Mingw-w64, but nearly no libraries. Stefan
Re: [Qemu-devel] Problems with native Mingw-w64 build
On 26 March 2017 at 11:30, Mark Cave-Aylandwrote: > In order to do some testing on a Windows box, I've spent a bit of time > this weekend setting up a mingw-w64 build environment on Windows 10 > using http://wiki.qemu-project.org/Hosts/W32 as a guideline. I think most people prefer to use the cross-compile. Stefan might do native compiles. > 2) glib-compat mkdtemp() error > This one seems to be a genuine bug since the wiki above mentions that > 64-bit builds cannot use versions of glib > 2.22 due to a change in the > way global symbols are managed. Since g_dir_make_tmp() only appears in > glib 2.30 and later, we end up using the fallback code which fails > because mkdtemp() isn't available on Windows. Since 2.7 the minimum version of glib has been 2.30 for Windows (documented in http://wiki.qemu-project.org/ChangeLog/2.7), because of this g_dir_make_tmp() dependency. Unfortunately it looks like we forgot to update configure (we didn't for 2.7 because we noticed the issue quite late in the release cycle). thanks -- PMM
[Qemu-devel] Problems with native Mingw-w64 build
Hi all, In order to do some testing on a Windows box, I've spent a bit of time this weekend setting up a mingw-w64 build environment on Windows 10 using http://wiki.qemu-project.org/Hosts/W32 as a guideline. After a few false starts, I was able to get the basic environment working but so far I've been unable to build git master due to a couple of failures: 1) texi2pod.pl error GEN qemu.1 Bareword found where operator expected at /c/Users/Mark/qemu/src/qemu/scripts/texi2pod.pl line 349, near "@(deftp" (Might be a runaway multi-line // string starting on line 337) (Missing operator before deftp?) Unquoted string "deftp" may clash with future reserved word at /c/Users/Mark/qemu/src/qemu/scripts/texi2pod.pl line 349. Backslash found where operator expected at /c/Users/Mark/qemu/src/qemu/scripts/texi2pod.pl line 349, near ")\" (Missing operator before \?) Unrecognized escape \s passed through at /c/Users/Mark/qemu/src/qemu/scripts/texi2pod.pl line 349. syntax error at /c/Users/Mark/qemu/src/qemu/scripts/texi2pod.pl line 349, near "@(deftp" Missing right curly or square bracket at /c/Users/Mark/qemu/src/qemu/scripts/texi2pod.pl line 534, at end of line Execution of /c/Users/Mark/qemu/src/qemu/scripts/texi2pod.pl aborted due to compilation errors. make: *** [qemu.1] Error 255 I'm not sure what the workaround for this is, however it is possible to get further with the build by passing --disable-docs to configure. 2) glib-compat mkdtemp() error CC qga/commands.o In file included from c:/Users/Mark/qemu/src/qemu/include/qemu/osdep.h:107:0, from qga/commands.c:13: c:/Users/Mark/qemu/src/qemu/include/glib-compat.h: In function 'qemu_g_dir_make_tmp': c:/Users/Mark/qemu/src/qemu/include/glib-compat.h:59:9: error: implicit declaration of function 'mkdtemp' [-Werror=implicit-function-declaration] if (mkdtemp(path) != NULL) { ^~~ c:/Users/Mark/qemu/src/qemu/include/glib-compat.h:59:5: error: nested extern declaration of 'mkdtemp' [-Werror=nested-externs] if (mkdtemp(path) != NULL) { ^~ c:/Users/Mark/qemu/src/qemu/include/glib-compat.h:59:23: error: comparison between pointer and integer [-Werror] if (mkdtemp(path) != NULL) { ^~ cc1.exe: all warnings being treated as errors make: *** [qga/commands.o] Error 1 This one seems to be a genuine bug since the wiki above mentions that 64-bit builds cannot use versions of glib > 2.22 due to a change in the way global symbols are managed. Since g_dir_make_tmp() only appears in glib 2.30 and later, we end up using the fallback code which fails because mkdtemp() isn't available on Windows. My guess would be that most people are using the Docker image to cross-compile Windows binaries rather than attempting a native build which is why no-one has really noticed (the mkdtemp() change went into the tree around August last year). Do people consider native Windows builds to still be supported? ATB, Mark.