Sorry, false alarm. It turned out one of my own files was using fopen/fclose and this was upseting things. After removing those it linked fine.
Martin Evans wrote: > I've just been tasked with porting our desktop embedded Python support > onto our existing CE offering. I've managed to compile the Python > sources and have produced an armdbg420\python23.lib file. > > When I come to link to the Python library though from our one of our > DLLs, I am getting the following unresolved externals: > > ------------------- > embedded.obj : error LNK2019: unresolved external symbol > "__declspec(dllimport) int __cdecl WinCE_fclose(void *)" > (__imp_?WinCE_fclose@@[EMAIL PROTECTED]) referenced in function "unsigned long > __cdecl PythonThread(void *)" (?PythonThread@@[EMAIL PROTECTED]) > > embedded.obj : error LNK2019: unresolved external symbol __imp_LoadLibraryU > referenced in function "unsigned long __cdecl PythonThread(void *)" > (?PythonThread@@[EMAIL PROTECTED]) > > embedded.obj : error LNK2019: unresolved external symbol > "__declspec(dllimport) void * __cdecl WinCE_fopen(char const *,char const > *)" (__imp_?WinCE_fopen@@[EMAIL PROTECTED]) referenced in function "void * > __cdecl > OpenScriptFile(unsigned short *)" (?OpenScriptFile@@[EMAIL PROTECTED]) > > ------------------- > > python23.lib does have entries for WinCE_fopen (part of > wince-compatibility.c) when looking at the lib file using dumpbin (all > are undecorated). Have I missed some vital step in producing it? > > > Just to clarify my environment, I am producing a PocketPC 2003 > application that embeds Python, scripts are launched within our > application with script output displayed in our own output window. We > also provide our own Python extension library. All works on ok on the > desktop version. > > Any help would gratefully appreciated. Thanks. > > Martin > -- http://mail.python.org/mailman/listinfo/python-list
