> Python extensions must be built using the same compiler as was used to > build the Python binary. Python 2.5.4 was built using MSVC2003 and so > extensions for it must be built using the same compiler. The exception > to this rule is that extensions built using mingw32 (and msys) will > work with most, if not all, windows Python binaries.
This is NOT correct. What you cannot do, is safely share CRT objects between different CRTs. You cannot malloc() some memory with msvcrt.dll, and subsequently free() the memory with msvcr71.dll. Similarly, you cannot fopen() a FILE* with msvcr71.dll and fread() with msvcrt.dll. Applications that do this will sooner or later fail in mysterious ways. Thus to be on the safe side, you should link the same CRT as Python and other native extensions use. That is, msvcr71.dll for Python 2.5. MSVC2003 usually does this by default, but there are exceptions. For example, Visual C++ 2003 Toolkit links against a static version of msvcr71. GCC (mingw) will by default link with msvcrt.dll. It will link with the same CRT as Python if you link with -lmsvcr71. You can create link libraries against this CRT for most compilers, you just need a .def file. Thus, you can use all compilers. If your extension DO NOT share its CRT objects with Python, it does not matter what compiler you use. IANAL, but there is a licensing issue one needs to be aware of: You are not allowed to redistribute msvcr71.dll except if you own a VS2003 license and have used that compiler. This is important if you use py2exe to create a Windows executable. This is one example where GCC cannot be used. But it is a legal issue, not a technical one. On the other hand, I don't think Microsoft has ever percecuted anyone for infringment of their msvcr71.dll copyright. They just want you to develop for their OS. But if you are going to use py2exe, you have to sort this problem out, or simply redistribute a full Python distro instead. In that case, PSF has built Python with a licensed VC2003 compiler, and you are just redustributing their binary installer (which is ok). Sturla Molden _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
