Leopold Toetsch wrote:

>Steve Hay <[EMAIL PROTECTED]> wrote:
>  
>
>>HANDLE __stdcall  WSAAsyncGetServByName(HWND hWnd, u_int wMsg,
>>                                        const char  * name,
>>                                        const char  * proto,
>>                                        char  * buf, int obj.u._b._buflen);
>>    
>>
>
>  
>
>>In fact, just running this:
>>    
>>
>
>  
>
>>#include "parrot/parrot.h"
>>    
>>
>
>#undef buflen
>
>  
>
>>#include "EXTERN.h"
>>#include "config.h"
>>#undef HAS_OFF64_T
>>#include "perl.h"
>>    
>>
>
>before including perl.h should do it for now.
>
Thanks - that works a treat.

The parrot build nearly worked OK now, but unfortunately it fell at the 
last hurdle:

        link -out:parrot.exe -nologo -nodefaultlib -debug     
-machine:x86  -debug imcc\main.obj blib/lib/libparrot_s.lib oldnames.lib 
kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib 
shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib wsock32.lib 
mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib
libparrot_s.lib(perl5xpvhv.obj) : error LNK2001: unresolved external 
symbol __imp__win32_malloc
libparrot_s.lib(perl5lv.obj) : error LNK2001: unresolved external symbol 
__imp__win32_malloc
libparrot_s.lib(perl5av.obj) : error LNK2001: unresolved external symbol 
__imp__win32_malloc
libparrot_s.lib(perl5xpvhv.obj) : error LNK2001: unresolved external 
symbol __imp__win32_abort
libparrot_s.lib(perl5lv.obj) : error LNK2001: unresolved external symbol 
__imp__win32_abort
libparrot_s.lib(perl5av.obj) : error LNK2001: unresolved external symbol 
__imp__win32_abort
libparrot_s.lib(perl5xpvhv.obj) : error LNK2001: unresolved external 
symbol __imp__win32_printf
libparrot_s.lib(perl5av.obj) : error LNK2001: unresolved external symbol 
__imp__win32_printf
parrot.exe : fatal error LNK1120: 3 unresolved externals
NMAKE : fatal error U1077: 'link' : return code '0x460'
Stop.

I've seen this sort of name munging problem on Win32 before, but I can't 
quite figure out what's wrong here.  I think it's usually something to 
do with object files or libraries that were compiled using different MS 
C run-time libraries being linked together, but as far as I can see 
everything was compiled with the same options.  Those options include 
-MD, which is correct for linking against msvcrt.lib.

Any ideas what's wrong?  Any Win32 gurus out there?

- Steve



------------------------------------------------
Radan Computational Ltd.

The information contained in this message and any files transmitted with it are 
confidential and intended for the addressee(s) only.  If you have received this 
message in error or there are any problems, please notify the sender immediately.  The 
unauthorized use, disclosure, copying or alteration of this message is strictly 
forbidden.  Note that any views or opinions presented in this email are solely those 
of the author and do not necessarily represent those of Radan Computational Ltd.  The 
recipient(s) of this message should check it and any attached files for viruses: Radan 
Computational will accept no liability for any damage caused by any virus transmitted 
by this email.

Reply via email to