Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

Thomas Jollans thomas at jollans.com
Tue Jul 6 13:09:21 EDT 2010


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.



More information about the Python-list mailing list