From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37257 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q8Hgq-00045t-Nd for qemu-devel@nongnu.org; Fri, 08 Apr 2011 15:49:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q8Hgp-0008H8-53 for qemu-devel@nongnu.org; Fri, 08 Apr 2011 15:49:56 -0400 Received: from moutng.kundenserver.de ([212.227.17.9]:57621) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q8Hgo-0008EZ-FV for qemu-devel@nongnu.org; Fri, 08 Apr 2011 15:49:54 -0400 Message-ID: <4D9F66DA.9000309@mail.berlios.de> Date: Fri, 08 Apr 2011 21:49:46 +0200 From: Stefan Weil MIME-Version: 1.0 References: <1301605129-12808-1-git-send-email-weil@mail.berlios.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH] w32: Fix compilation of new code List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Paolo Bonzini , Anthony Liguori , QEMU Developers Am 03.04.2011 11:10, schrieb Blue Swirl: > On Thu, Mar 31, 2011 at 11:58 PM, Stefan Weil > wrote: >> Some recently added new code did not compile for w32 targets. >> >> The functions qemu_iohandler_fill and qemu_iohandler_poll need >> data type fd_set which is declared in winsock2.h for w32 targets. >> >> Moving the functions from qemu-common.h to qemu_socket.h fixes >> compilations for w32 without adding a new include file to qemu-common.h. > > There's nothing socket specific in qemu_iohandler_fill and > qemu_iohandler_poll, so I'd rather fix qemu-common.h. But I have a > patch in my working queue to move OS specific stuff to qemu-common.h, > I'll fix this there. Should I send a patch for qemu-common.h? This would need inclusion of winsock2.h for windows and fixing a conflict with json-lexer.c (which uses an enum value named ERROR)? w32 builds are now broken for more than a week (since 2011-03-29, commit 0298141998ea3e19fd86b5a7122aab2fd1ebad51). Best regards, Stefan