>> You need unofficial version of MinGW with gcc 4.x for several C++ >> extension like PyLucene's JCC. Some project like pywin32 don't work with >> MinGW, too. > > aha - why is that? > > But - if you write code that builds with [whatever gcc version you > have], the compiler Python is built with shouldn't matter, should it?
Unless I'm mistaken, official MinGW32 packages still have GCC 3.x. Some projects like JCC need recent C++ compilers. MinGW doesn't provide some features that pywin32 requires. The compiler must create ABI compatible object files and the linker needs to support the latest CRT. Three years ago it took several months until MinGW supported the 9.0 CRT. > Okay, you need to be careful with FILE*s. But malloc and free? You'd > normally only alloc & free something within the same module, using the > same functions (ie not mixing PyMem_Malloc and malloc), would you not? > > You have to code quite defensively, true. But, IF you keep all > non-Python data structures local to your module, you should be fine? You must be carefully with functions like PyFile_FromFile(), too. If you expose the FILE* from the alien CRT to Python somehow you can get into trouble. Lukely PyFile_FromFile() works around most issues but it's still problematic. These kind of SEGFAULTs are hard to debug, too. > Coming from a system where I can generally rely on the system gcc to > work for everything, I may be a bit naïve wrt certain questions ;-) > > PS: Windows CPython programming scares me. Yeah, it's a pain. -- http://mail.python.org/mailman/listinfo/python-list
