This is the mail archive of the newlib@sources.redhat.com mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

newlib 1.12.0 compiled under different cygwin versions


When mallocr.c gets compiled using the current cygwin devel base (gcc 3.3.3), the following symbols are undefined:

         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
         #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). I am trying to chase down changes to winbase.h, but thought I would check here first... does anyone have any theories?

Many thanks.

--
Craig Edwards


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]