From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2647 invoked by alias); 23 Aug 2012 16:52:27 -0000 Received: (qmail 2636 invoked by uid 22791); 23 Aug 2012 16:52:25 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,TW_FN,TW_UU X-Spam-Check-By: sourceware.org Received: from smtpout.karoo.kcom.com (HELO smtpout.karoo.kcom.com) (212.50.160.34) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 23 Aug 2012 16:52:12 +0000 Received: from 213-152-38-55.dsl.eclipse.net.uk (HELO [192.168.1.103]) ([213.152.38.55]) by smtpout.karoo.kcom.com with ESMTP; 23 Aug 2012 17:51:35 +0100 Message-ID: <50365FA8.60709@dronecode.org.uk> Date: Thu, 23 Aug 2012 16:52:00 -0000 From: Jon TURNEY User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: cygwin-apps@cygwin.com CC: jon_y-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Subject: Re: [ITA] w32api-3.0b_svn5368-1 References: <20120814072938.GA13181@calimero.vinschen.de> <20120814073403.GB13181@calimero.vinschen.de> <20120814075611.GC13181@calimero.vinschen.de> <50322A61.1050806@users.sourceforge.net> <5032C6C9.4070704@users.sourceforge.net> <5032E14F.5090604@users.sourceforge.net> <5032F137.2070905@users.sourceforge.net> <5033010B.1020509@users.sourceforge.net> <20120821034635.GA17755@ednor.casa.cgf.cx> <503312FD.4030305@users.sourceforge.net> <50336CEB.6060900@dronecode.org.uk> <50337233.4030205@users.sourceforge.net> <50339789.7060304@dronecode.org.uk> <5033DA5A.2090803@users.sourceforge.net> <50340B1D.2070302@users.sourceforge.net> <5034A17F.4090209@users.sourceforge.net> In-Reply-To: <5034A17F.4090209@users.sourceforge.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-apps-help@cygwin.com; run by ezmlm Precedence: bulk Sender: cygwin-apps-owner@cygwin.com List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps@cygwin.com X-SW-Source: 2012-08/txt/msg00094.txt.bz2 On 22/08/2012 10:08, JonY wrote: > On 8/22/2012 06:26, JonY wrote: >>> According to mingw.org , GUID_SECT was only necessary for >>> ancient GCC versions. At a minimum, we should be able to just remove >>> the GUID_SECT from those defines. Unfortunately just ifndef _W64 those >>> defines entirely leads to link errors: >>> >>> hw/xwin/winengine.c:107: undefined reference to `_IID_IDirectDraw4' >>> winshaddd.o: In function `winAllocateFBShadowDD': >>> hw/xwin/winshaddd.c:253: undefined reference to `_IID_IDirectDraw2' >>> winshadddnl.o: In function `winAllocateFBShadowDDNL': >>> hw/xwin/winshadddnl.c:285: undefined reference to `_IID_IDirectDraw4' >>> winpfbdd.o: In function `winAllocateFBPrimaryDD': >>> hw/xwin/winpfbdd.c:89: undefined reference to `_IID_IDirectDraw2' It's pretty easy to adapt for this in the existing X server code either by simply defining GUID_SECT as empty if it is not already defined, or removing GUID_SECT. >> mingw-w64 ddraw.h already has them, though they're inlined, gcc doesn't >> like inlined data. DEFINE_GUID may need fixing, or at least instanced in >> libuuid or libddraw. >> >> I'll need to talk to to the Jacek from Wine to get a solution. >> > > Here's a quick and dirty workaround, add and compile the following file > and link it with the failing executable: > > ===================== > #define INITGUID 1 > #include > ===================== It's tempting to conclude that the "brokeness" alluded to in the comment in the X server source is that the author didn't know about INITGUID. It seems that GUID_SECT is defined by the current w32api headers, but only had any contents for ancient gcc (prior to 2.95) However, Google seems to indicate that we are not totally alone in assuming the existence of GUID_SECT, so you might want to consider providing an empty definition for compatibility.