On 17/06/2006 3:49 AM, Chris Botos wrote: > James Carroll wrote: >>> Thanks for your responses. I went ahead and tried MinGW. I was able to >>> build and use screengrabber and other examples. I also used it as an >>> example and created successfully a very simple "hello python" extension. >> Fantastic! they must be more (binary) compatable than I thought. > > Well, ... I've managed to crash python by using an "ostream" rather than > "printf". The code is below. If I replace the std::cout with a printf > the code works fine. The symptom is that the cout is flushed to the > console as it should be, then the python shell hangs. A few seconds > later a "send error report to microsoft" dialog comes up. Here's some > of the information it provided, in addition to saying it was an > unhandled exception: > Error Signature: > AppName: python.exe AppVer: 0.0.0.0 ModName: ntdll.dll > ModVer: 5.1.2600.2180 Offset: 00018fea > > I'm using > Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on > win32; MinGW Developer Studio 2.05. > Does anyone know what I'm doing wrong?
You said it yourself: """using an "ostream" rather than "printf"""". My guess would be that the MinGW C++ cout data structures are not initialised. My experiences, FWIW: I've been using both MinGW and Borland 5.5 for ages, for extensions that I've written myself in C, and also using Borland to compile the C code generated by Pyrex. I've never tried to wrap an existing C library. Here are my rules for staying out of trouble: 1. Use C, not C++. 2. If there is a function in the Python/C API that does the job, use it in preference to an RTL function. This applies especially to malloc() and free(). 3. Don't try to use resources across RTL boundaries e.g. trying MinGW fwrite() on a (FILE *) that was opened by the MSC RTL and obtained by calling PyFile_AsFile() HTH John _______________________________________________ Python-win32 mailing list Python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32
