qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Win32 QEMU binaries built from MinGW fail (access viola


From: Dan
Subject: Re: [Qemu-devel] Win32 QEMU binaries built from MinGW fail (access violation)
Date: Sun, 26 May 2013 14:54:35 -0500

Success.... of sorts.  The new tool-chain seems to have fixed the
issue, but I seemed to have to use a meat cleaver to get it install
properly.  In any case, I have a QEMU build working, but extremely
slowly.  At this point I am content that QEMU can be built FROM
windows FOR windows, but someone might want to straighten up the
QEMU/MinGW documentation.  It is not nearly as straight forward as it
sounds, and I think use of MinGW-w64 should become the ONLY supported
MinGW tool chain.  My experience with the older MinGW was far from
favorable.

I did get a reply from another FROM windows FOR windows builder, and
it does look like all problems are related to my tool chain.  I'll
spend some time this summer trying to figure out how to build up the
MinGW-w64 build environment "properly" without the use of my meat
cleaver.  If I ever get a clean result that I'm happy with I'll post
my results and would be happy to contribute to the documentation when
the time comes.

Thanks again for your tips... and please let me know if you find a
good MinGW-w64 primmer you would suggest.

ref1: http://wiki.qemu.org/Hosts/W32
ref2: http://en.wikibooks.org/wiki/QEMU/MinGW

Long explination at:
http://screamingmonkeys.blogspot.com/2013/05/qemu-with-mingw-use-source-luke.html

On Sat, May 25, 2013 at 3:52 AM, Dan <address@hidden> wrote:
> Great Idea... never occurred to me that gdb would actually work in MinGW
>
> So I tried that, specifically adding "--enable-debug --disable-pie"
> (ref1) and now the failure went away, but it is DOG slow!
>
> I will try the following this weekend and report back:
> 1) Try another MinGW-w32 build without "--disable-pie" to see if the
> bug comes back despite (ref1).
> 2) Wipe my Cygwin and MinGW directories, and rebuild with the following:
>    a) Cygwin with {MinGW-w64 zlib gettext libiconv glib pkg-config} installed
>    b) Download libSDL and "make native"
> 3) Download Qemu source and rebuild with new tool chain.
>    a) If I get a crash, retry with debugging.
> 4) As a last resort, wipe and reload, this time using the Gtk+ bundle
> instead of Cygwin repositories.
> 5) Repeat 1-4 as needed on Windows 8 x64 system and Windows Vista x86 system.
>
> In either case, I should have some good results in a few days.
>
> Thanks for the help.
>
> ref1: http://stackoverflow.com/a/14276340
>
> On Sat, May 25, 2013 at 1:27 AM, Stefan Weil <address@hidden> wrote:
>> Am 25.05.2013 03:56, schrieb Dan:
>>> I've been trying to build QEMU source directly with MinGW.  The
>>> compile/link works but there are tons of warnings (mostly Wformat).
>>> Once I try to run the binaries in Windows though, I quickly hit access
>>> violations once the HD image is mounted.  I've tested on the
>>> linux-0.2.img.bz2 so that I can be consistent with others.  The
>>> violations bounce around based on the image and emulation.  I've tried
>>> with -nographic to try to rule out SDL.dll.  I'm at a loss, and
>>> beginning to wonder if 100's of Wformat errors need to be patched one
>>> by one to have a run-able windows binary.
>>>
>>> What I'm confused by is that both qemu.org (ref1) and wikibooks.org
>>> (ref2) seem to imply that there are no special MinGW patches.  I've
>>> also found many sites hosting valid QEMU win32 binaries like
>>> omledom.com (ref3).  I've even ensured that my ./configure settings
>>> match theirs (omledom), but of course I have no way to know if they
>>> are compiliing FROM windows FOR windows, or FROM linux FOR windows.
>>>
>>> Here's is an abridged list of my process.
>>>
>>> install cygwin to for wget and unzip, though nothing is in the PATH varable.
>>> wget mingw-get-inst-20120426.exe
>>> wget python-2.6.6.msi
>>> wget gtk+-bundle_2.24.10-20120208_win32.zip
>>> wget SDL-devel-1.2.15-mingw32.tar.gz
>>> wget qemu-1.4.1.tar.bz2
>>> wget linux-0.2.img.bz2
>>>
>>> install mingw-get-inst-20120426.exe
>>> install python-2.6.6.msi
>>> unzip gtk+-bundle_2.24.10-20120208_win32.zip to c:\MinGW
>>> unzip SDL-devel-1.2.15-mingw32.tar.gz to c:\MinGW\msys\1.0\src
>>> unzip qemu-1.4.1.tar.bz2 to c:\MinGW\msys\1.0\src
>>> decompress linux-0.2.img.bz2 to c:\MinGW\msys\1.0\bld
>>>
>>> launch msys prompt && cd /usr/src/SDL && make native
>>> launch msys prompt && cd /usr/src/qemu
>>> ./configure --python=c:/Python26/python.exe --prefix=/usr/bld
>>> make && make install && cd /usr/bld
>>> ./qemu-system-i386.exe linux-0.2.img
>>>
>>> Observe an access violation in qemu-system-i386.exe within 5 seconds.
>>>
>>> Am I the only one compiling qemu FROM windows FOR windows?
>>>
>>> Also, just for grins, I replace my copy of qemu-system-i386.exe with
>>> the one from omledom and things work without any issues.  I've also
>>> tried the qemu 1.5 repositories and this weeks .git snapshot.  All
>>> fail with similar errors.
>>>
>>> I've also done this on two machines, an x86 Windows Vista system and
>>> an x64 Windows 8 system.  Same results on both.
>>>
>>> ref1: http://wiki.qemu.org/Hosts/W32
>>> ref2: http://en.wikibooks.org/wiki/QEMU/MinGW
>>> ref3: http://www.omledom.com/
>>>
>>> Long explanation at:
>>> http://screamingmonkeys.blogspot.com/2013/05/return-to-linux-compiling-qemu-with.html
>>>
>>> -Dan
>>
>> Hi Dan,
>>
>> native builds for Windows should work and result in working executables.
>> Can you run qemu-system-i386 with gdb and provide a stack trace of the
>> crash?
>>
>> The Wformat warnings are "normal" with unpatched versions of MinGW32
>> because MinGW32 does not correctly set the ANSI format macros
>> (PRIu32, ...).
>>
>> I recommend using MinGW-w64. It is installed on top of MinGW and includes
>> newer and better system include files as well as compilers for 32 and 64 bit
>> executables, so you can compile for w32 and for w64.
>>
>> Cheers
>> Stefan
>>
>>
>> qemu-system-i386
>>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]