On 07/06/2010 06:58 PM, Christian Heimes wrote: > Am 06.07.2010 18:21, schrieb Thomas Jollans: >> mingw gcc should work for building C++ extensions if it also works for C >> extensions. There's no difference on the binding side - you simply have >> to include everything as extern "C", which I am sure the header does for >> you. > > 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? > >> Also, VS2010 should work as well - doesn't it? > > It may work, it may segfault. > > The official Python binaries are build with VS 2008. Although you are > able to build and use extensions build with other versions of VS it can > lead to segfaults. So far every version of VS has introduced its own C > runtime library (MSVCRT). If you try to close a FILE* from one MSVCRT > with fclose() from another MSVCRT your program SEGFAULT. malloc() and > free() suffer from the same problem. 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? 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 ;-) Cheers, Thomas PS: Windows CPython programming scares me. -- http://mail.python.org/mailman/listinfo/python-list