qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] QEMU 2.4 for Windows - current status


From: Stefan Weil
Subject: [Qemu-devel] QEMU 2.4 for Windows - current status
Date: Wed, 05 Aug 2015 13:03:51 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0

Am 05.08.2015 um 11:52 schrieb Daniel P. Berrange:
On Fri, Jul 31, 2015 at 07:58:45PM +0200, Stefan Weil wrote:
Am 31.07.2015 um 14:49 schrieb Paolo Bonzini:
On 31/07/2015 12:17, Daniel P. Berrange wrote:
   CC    util/osdep.o
In file included from include/qemu-common.h:48:0,
                  from util/osdep.c:48:
include/sysemu/os-win32.h:77:12: error: redundant redeclaration of 'gmtime_r' 
[-Werror=redundant-decls]
  struct tm *gmtime_r(const time_t *timep, struct tm *result);
             ^
In file included from include/qemu-common.h:35:0,
                  from util/osdep.c:48:
/usr/i686-w64-mingw32/sys-root/mingw/include/time.h:272:107: note: previous 
definition of 'gmtime_r' was here
In file included from include/qemu-common.h:48:0,
                  from util/osdep.c:48:
include/sysemu/os-win32.h:79:12: error: redundant redeclaration of 
'localtime_r' [-Werror=redundant-decls]
  struct tm *localtime_r(const time_t *timep, struct tm *result);
             ^
In file included from include/qemu-common.h:35:0,
                  from util/osdep.c:48:
/usr/i686-w64-mingw32/sys-root/mingw/include/time.h:269:107: note: previous 
definition of 'localtime_r' was here

This change adds a configure test to see if localtime_r
exits, and only enables the QEMU impl if missing. We also
re-arrange qemu-common.h try attempt to guarantee that all
source files get unistd.h before time.h and thus see the
localtime_r/gmtime_r defs.
These are only with --enable-werror, right?  The patch shouldn't be
necessary for 2.4.

Paolo
It isn't necessary for 2.4. There are more severe problems which also
seem to be triggered by recent changes in the MinGW-w64 toolchain:

64 bit executables crash at longjmp from generated code,
and networking fails because of asynchronous connect calls
which were never implemented correctly in the slirp code.
I'll try to summarize all that I know in a separate mail later.

I only recently got reports about these problems and think
that it is too late to fix them in 2.4.0.
Could you post the info about these problems, or point me to the bug
reports. I'm currently trying to get a patchset of mine working on
Win32 so need to understand what's broken with Mingw/Win32 currently.

Regards,
Daniel

Sorry for the delay - I have currently only sporadic
internet access.

I recently upgraded my build environment from Debian Wheezy
to Debian Jessie. Obviously the newer MinGW-w64 packages
introduced several problems for QEMU:

* Compiler warnings caused by newer compiler and changes in
system include files

* Modified order of include files and definitions. This results in
a wrong sigsetjmp call in cpu-exec.c for 64 bit code.
That code will crash as soon as there is a longjmp returning
from generated TCG code because that code does not support
stack unwinding.

* Asynchronous connect call. Obviously TCP connect was
synchronous with earlier versions. Now it can also fail,
but Windows does not set errno (slirp expects errno code).
This results in buggy networking with all Windows versions
of QEMU (any connect will fail).

Here are two hacks to fix these problems:

Fix sigsetjmp for w64
http://repo.or.cz/w/qemu/ar7.git/commit/8fa9c07c9a33174905e67589bea6be3e278712cb

slirp: Fix non blocking connect for w32
http://repo.or.cz/w/qemu/ar7.git/commit/b3f21d56ad3f36562d396685de8ff4981af6b805

At least the first patch (maybe also the 2nd one) will
also be needed for old versions of QEMU as they
don't depend on the QEMU version but on the
version of MinGW-w64.

Regards
Stefan




reply via email to

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