Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Date: Tue, 14 Dec 2004 08:40:30 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: "cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Subject: Re: newlib 1.12.0 compiled under different cygwin versions
Message-ID: <20041214074030.GB1685@cygbert.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: "cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
References: <opsiyqrbs81jf2l8 AT edwardsc DOT au DOT ibm DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <opsiyqrbs81jf2l8@edwardsc.au.ibm.com>
User-Agent: Mutt/1.4.2i

On Dec 14 07:19, Craig Edwards wrote:
> When mallocr.c gets compiled using the current cygwin devel base (gcc  
> 3.3.3), the following symbols are undefined (presumably linked in from a  
> Win32 DLL):
> 
>          U __imp__LocalAlloc AT 8
>          U __imp__LocalFree AT 4
>          U __imp__VirtualAlloc AT 16
>          U __imp__VirtualFree AT 12
>          U __imp__VirtualQuery AT 12
> 
> However, in a slightly older cygwin (using gcc 3.3.1), the undefined  
> symbols are:
> 
>          U _LocalAlloc AT 8
>          U _LocalFree AT 4
>          U _VirtualAlloc AT 16
>          U _VirtualFree AT 12
>          U _VirtualQuery AT 12
> 
> Now, these functions are declared in winbase.h (included indirectly by  
> mallocr.c) as follows:
> 
>          #ifndef WINBASEAPI
>          #ifdef __INSIDE_CYGWIN__
>          #define WINBASEAPI
>          #else
>          #define WINBASEAPI DECLSPEC_IMPORT
>          #endif
> 
>          WINBASEAPI PVOID WINAPI VirtualAlloc(PVOID,DWORD,DWORD,DWORD);
>          ...
> 
> I can see that currently it thinks these functions are to be imported from  
> a DLL, but why did it used to behave differently?  The reason I care is  
> that my XBOX port of newlib provides its own implementation of those  
> functions that get *statically* linked in to libc.a (which used to work  
> just fine until I upgraded to a later version of cygwin).  Does anyone  
> have any theories?

That's due to the above change in w32api which is maintained mainly by
the MingW team.  Perhaps you should ask on mingw-users AT sourceforge DOT net
for the actual motivation.  However, you should be able to circumvent
the problem by defining WINBASEAPI.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          mailto:cygwin AT cygwin DOT com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/