[Top][All Lists]

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

Re: [Qemu-devel] broken socket events on win32 qemu

From: Andrew Baumann
Subject: Re: [Qemu-devel] broken socket events on win32 qemu
Date: Mon, 7 Mar 2016 18:23:47 +0000

> From: Daniel P. Berrange [mailto:address@hidden
> Sent: Monday, 7 March 2016 2:19 AM
> On Mon, Mar 07, 2016 at 07:23:12AM +0000, Andrew Baumann wrote:
> > BTW, The same change introduces another problem on win32: server
> sockets
> > like the GDB example above fail on getpeername() with "Unable to query
> >  remote socket address: Unknown error". This seems to be caused by a
> > definition of ENOTCONN that is not WSAENOTCONN. I'm still trying to
> > figure out why that is, and how to best fix it.
> Can you say how you are building QEMU ? Are you using mingw to do a cross
> compile for Win32, or something else ?

I'm building natively using an unhealthy mixture of mingw-w64 and gcc installed 
from win-builds, 32-bit tools from a native mingw/msys installation, and 
probably some Cygwin stuff that leaked into my PATH as well. (It's a setup that 
evolved, not one I'd advise replicating! :)

> Looking at my local Mingw64 install, the errno definitions look potentially
> problematic· The QEMU  socket_error() method is quite crude - it simply
> expands to WSAGetLastError(), so any code calling it is assuming that the
> WSAExxxxx constants match the Exxxx constants. QEMU has a header which
> sets up such a mapping, but it only does so conditionally. eg in
> include/sysemu/os-win32.h
>   #ifndef ENOTCONN
>   #endif
> The current versions of mingw64 I have installed though has a winerror.h
> which defines
>   #define WSABASEERR 10000
> And a separate  errno.h that defines
>   #ifndef ENOTCONN
>   #define ENOTCONN 126
>   #endif
> This obviously does not match the WSAENOTCONN value
> So my guess would be that QEMU is pulling in the mingw64 errno.h values
> and so QEMU's own  os-win32.h hack is not getting activated.

Yes, I’m seeing the same thing. I will test your patch, but it looks like the 
right thing to do for the socket errors.


reply via email to

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