I still can’t see how to build this for win64 … 🙁
The first major stumbling block on Win32 is glib, and again going back to the MinGW wiki there is a good laundry list of how to bootstrap Glib on MinGW.
Things you’ll need:
Be sure to run ming-get install for the following:
- gcc
- g++
- libiconv
- zlib
- libz
- gettext
- msys
- msys-perl
- msys-m4
Install Python.. Nothing to fancy from what I gather Qemu still requires you have a level 2 Python, not 3 …
Build libffi
This should be the usual dance of configure & make / make install… Â But sure to at least run configure like this:
./configure –prefix=/mingw
Build Glib without pkg-config
Be sure to add Python to your path..
PATH=/c/Python27:/c/Python27/DLLs:$PATH
export PATH
Glib is packed with something called ‘xz’ so hopefully you have xzcat .. Otherwise add it!
export LIBFFI_CFLAGS=’-I /mingw/lib/libffi-3.0.9/include’
export LIBFFI_LIBS=-lffi
export lt_cv_deplibs_check_method=”pass_all”
export CFLAGS=â€-O0 -g -pipe -Wall -march=i486 -mms-bitfields -mthreadsâ€
export CPPFLAGS=â€-DG_ATOMIC_OP_USE_GCC_BUILTINS=1â€
export LDFLAGS=â€-Wl,–enable-auto-image-baseâ€
configure –prefix=/mingw –with-pcre=internal –disable-static –disable-gtk-doc –enable-silent-rules
*Â You may have some weird issue where when running configure it tells you it cannot create executables, or you get a bunch of weird errors trying to paste in the CFLAGS line.. For me the MinGW prompt was stripping the quotes and the leading – to the -O0 (disable optimization) bit. Â I don’t know what on earth its issue was, but I had to type that line in manually.
Then do the make/make install dance. This will take a WHILE. At least with -pipe it’ll run each stage of GCC on multiple processors… But yeah.. This is intense to build. Â Good thing we get to do it twice.
I also ran into some weird error in the GIO directory where it couldn’t find my Python, and was looking for python2.5 .. So I copied python.exe to python2.5.exe …
PYTHON = /usr/bin/env python2.5
pkg-config
Naturally pkg-config depends on Glib2, and pkg-config to build… Which of course is a circular problem, much like Glib2 requires pkg-config to build. Â So to configure it, it goes something like this now that we’ve built a Glib2 ..
export GLIB_CFLAGS=”-I/mingw/include/glib-2.0 -I/mingw/lib/glib-2.0/include”
export GLIB_LIBS=”-lglib-2.0″
configure –prefix=/mingw
At the same time I can’t help but wonder if this version of pkg-config can use it’s own Glib with the following config:
configure –prefix=/mingw –with-internal-glib
Anyways with any luck we can now build & install pkg-config. Â This only takes a few seconds..
Glib2 (again)
From this point you should open a new MinGW prompt window, as you don’t want the old CFLAGS screwing things up. Â Re-eport the Python path/dll vars and now we can get on to building glib2 (again!) …
configure –prefix=/mingw;make;make install
SDL
This should be somewhat straightforward …
configure –prefix=/mingw;make;make install
In the old days we built zlib, but now we can just quickly add in the package (as we did way above) so we should.. now be ready for the main event!
And now we can finally build Qemu 1.1.1-1!!!
Now there is a few things I like to tweak, the first is in the configure script, I like to add in AdLib support. Â Look for the line
audio_card_list=”ac97 es1370 sb16 hda”
and add adlib into the list
audio_card_list=”ac97 es1370 sb16 hda adlib”
Next I like to modify hw/pc.c and alter the ISA NE2000, as Qemu doesn’t like to share IRQ 9 with the card, so it is just easier to remove the 0x300/IRQ 9 definition.
static const int ne2000_io[NE2000_NB_MAX] = { 0x300, 0x320, 0x340, 0x360,
0x280, 0x380 };
static const int ne2000_irq[NE2000_NB_MAX] = { 9, 10, 11, 3, 4, 5 };
to this:
static const int ne2000_io[NE2000_NB_MAX] = { 0x320, 0x340, 0x360,
0x280, 0x380 };
static const int ne2000_irq[NE2000_NB_MAX] = { 10, 11, 3, 4, 5 };
The next tweak deals with the ability to use older qcow2 disk images… I guess converting them to RAW with an older version of Qemu, then using the new version of Qemu to convert them back into qcow2’s may be a “good ideaâ„¢” but for now modifying the source is a quicker fix.
Comment out the “return -EINVAL;” in block/qcow2.c
if (ext.len > end_offset – offset) {
error_report(“Header extension too large”);
//return -EINVAL;
}
Now one fun thing I’ve noticed is that building with the default O2 flags Qemu will crash out the moment you access a hard disk image.  It appears that coroutine-win32 is at issue (again?).  So the “easy” way I address it is to first build qemu as normal, and verify that if you attach a hard disk image (any kind) and try to access it, partition it etc, it should crash.  Next remove the file coroutine-win32.o , and edit the file config-host.mak and change the CFLAGS that specify
CFLAGS=-O2 -g
to
CFLAGS=-O1 -g
Now run make again, and it *should* just rebuild coroutine-win32.o with the lesser optimization flags, and relink all the exe’s.  If I’ve done this right, you should now have a working Qemu.
You can go ahead and strip the binaries if you so please, but that should be it.
PHEW. Â For anyone who wants my build, but doesn’t want to go through this ‘exciting’ process, you can find the Win32 i386 build here.
In preliminary testing I’ve found this version to be MUCH slower than 0.15.1 .. I think it has something to do with it wanting to scale the SDL window.  Also I’ve had issues with various network cards not initializing with the BIOS that ships with this version of Qemu so I’ve included the bios directory from 0.15.1 .  And lastly yes the disk images… I’ve had major issues with my qcow2 disks, and disk corruption with this build.  I’ve gone ahead and  included the qemu-img tool from 0.15.1 so you can convert qcow2 to raw, then use the 1.1.1 tool to take them from raw back into qcow2 … But I’d probably only do it as a test.
You may want to kick the tires on this version but 0.15.1 really blows this one away…
Thank you to make available Qemu for Windows!
I do not know much about Linux right now, but i really deserve to learn more about it in the future. I just know something about network administration and blah blah blah, and your build at the finish of the post helped me a lot of right now. One day i’ll make mine build too, when i learn to use “make”.
Obrigado! (Thank you in Portuguese). Just sorry the bad English :/
No problem! Glad I could help! .. I always wanted to see the cork trees & try the Linguiça of Portugal…
Qemu has become more & more difficult, you’d be surprised how few people manage to get it to build.
Once upon a time I was going to do a ‘pain free linux’ which became the 4.2 BSD on Windows thing… I should do it one day..
Im trying to find a staticly compiled .exe for target i386 emulation i tried to compile myself but it seems gcc versions on cygwin are incompatible someway with qemu, even tried with mingw binaries, cross compiling but there’s always some issues.. the goal is to have a single .exe (bloated but is ok) independent of any other dll’s for portable (clean) use if someone achieved this can please post a link of actual binary? meanwhile i’ll try to run step by step any tuts i find and if achieved i’ll post it myself
(funny i’m actually portuguese also and im just googling for qemu) as he said.. Obrigado!
Building Qemu can be somewhat involved.. going the static route is quite hard on Win32 as later versions of GCC tend to require you pull in other DLL’s.. which in its own can be quite vexing.
If you look on my vpsland site, there is quite a few binaries and stuff to dig through….
If you like installable packages, check out my old 386 BSD thing.. the NSIS source should be in there as well.
Oh and although not that Portugese per say, but a friend from Brazil first showed me Qemu soo.. 🙂
i was testing around with “configure –static” which even in msys or cygwin it compiles statically i guess, the .exe will be big, but that’s expected.. my problems are the gcc versions on cygwin
one doesn’t support “__thread” keyword the other just doesn’t detect as it is gcc4
but I actually found something…
https://sites.google.com/site/qemuwin/
it seems that only requires a sdl.dll which i wont use it since i will not start in a separate window, but unfortunately isn’t a newer version.. but i guess it will do it for now..
i’m currently living in brasil (i’m portuguese) and its a great country ;).. Obrigado again
oh wow that is ancient, 0.9! .. although that train did have good ISA emulation, good enough to run Novell Netware! ..
SDL is used for graphics, keyboard and sound..
I always hear Brazil is nice to visit, but rough to live in.. I guess we’ll find out with the build up to the world cup!
Yes i’m familiar with SDL..
i finally been able to build it, not that hard after know :), i did the mingw method, just installed it and unarchived the gtk+ inside it, and voila, the only issue i had was in configure –static, wasn’t finding the zlib in static mode, but it turns out i just had to rename libz.dll.a to libz.a
life brazil, well depends can be good in certain locations, but generally there are high taxes wich sucks, but some ppl can live with it 😉
cool, I’d recommend altering the SDL keyboard code to add control+alt+d to do a CAD… NT is unusable in Qemu without that.. and control+alt+r for a reset helps pesky MS-DOS as well… Oh and don’t forget to enable the sound blaster & Adlib, and ‘fix’ the NE2000 to use IRQ 10, since Qemu can’t share IRQ 9 anymore…..
I’ve compiled Qemu 2.7.0-rc1 on Windows XP using Cygwin (I installed all the development section to avoid the hunting of dependencies) and the build was successful, however I cannot run Qemu on Wine and on Windows XP but only on Windows 7 and ongoing because it asks me a lot of dlls that are not present in Windows XP, bcrypt.dll is one of those. Your build works absolutely fine.
I guess this is caused by the version of GTK that I’m using. on GTK’s website you can read:
“The current GTK+ stack uses APIs that are available only on Windows Vista or later.
If you require builds for unsupported versions of Windows, you should do a custom build of an older version of GLib and GTK+.”
It talks about GLib 2.48 and I have Glib 2.49 installed with Cygwin. Can you explain me where did you download and Install msys? I installed the packages from http://www.mingw.org. How long does it take to compile GLib under a virtual machine? Someone says even more than 7 hours. I really need some help. I wasted a lot of time for this. I found these packages on the Qemu wiki page that talks about cross compiling the emulator. How do I install them?
See:
http://wiki.qemu.org/Hosts/W32#Libraries_.28also_needed_for_cross_builds.29
ok, I’m trying to compile qemu-2.7.0-rc4 using this tutorial and a lot of other packages need to be installed with mingw-get
– automake
– autoconf
– libtool
When I extract the source tar miserably fails to make a couple of symbolik lynks
.1) /qemu-src/roms/u-boot/tools/patman/patman -> /qemu-src/roms/u-boot/tools/patman/patman.py
2) /qemu-src/roms/u-boot/tools/buildman/buildman -> /qemu-src/roms/u-boot/tools/buildman/buildman.py
when I compile the program I get this error
C:/MinGW/include/glib-2.0/glib/gmem.h:70:7: note: expected ‘gpointer’ but argument is of type ‘int’
void g_free (gpointer mem);
^
make: *** [qga/commands-win32.o] Error 1
this is my configure command (all in one line of course)
$ ../qemu-2.7.0-rc4/configure –target-list=i386-softmmu –prefix=./Qemu-2.7.0-r4_win32/ –docdir=./Qemu-2.7.0-r4_win32/Doc –with-confsuffix=/Bios –cc=gcc –cxx=g++ –disable-werror
I’m building out of source tree
I doubt it’ll build anywhere near as cleanly as qemu has become heavily linux/glib2 dependent…. it may be easier to cross build it from Linux.
Today i successfully built qemu-2.4.1 using the same toolchain that i used to build this