Mail Archives: cygwin/2004/12/14/02:38:35
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/
- Raw text -