newlib 1.12.0 compiled under different cygwin versions

Corinna Vinschen
Tue Dec 14 07:38:00 GMT 2004

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@8
>          U __imp__LocalFree@4
>          U __imp__VirtualAlloc@16
>          U __imp__VirtualFree@12
>          U __imp__VirtualQuery@12
> However, in a slightly older cygwin (using gcc 3.3.1), the undefined  
> symbols are:
>          U _LocalAlloc@8
>          U _LocalFree@4
>          U _VirtualAlloc@16
>          U _VirtualFree@12
>          U _VirtualQuery@12
> Now, these functions are declared in winbase.h (included indirectly by  
> mallocr.c) as follows:
>          #ifndef WINBASEAPI
>          #ifdef __INSIDE_CYGWIN__
>          #define WINBASEAPI
>          #else
>          #endif
>          ...
> 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
for the actual motivation.  However, you should be able to circumvent
the problem by defining WINBASEAPI.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader
Red Hat, Inc.

Unsubscribe info:
Problem reports:

More information about the Cygwin mailing list