Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
in [Python]
|
Prev: Python GUI for C program [was: ]
Next: Download Microsoft C/C++ compiler for use with Python 2.6/2.7ASAP
From: sturlamolden on 6 Jul 2010 11:50 Just a little reminder: Microsoft has withdrawn VS2008 in favor of VS2010. The express version is also unavailable for download. >:(( We can still get a VC++ 2008 compiler required to build extensions for the official Python 2.6 and 2.7 binary installers here (Windows 7 SDK for .NET 3.5 SP1): http://www.microsoft.com/downloads/details.aspx?familyid=71DEB800-C591-4F97-A900-BEA146E4FAE1&displaylang=en Download today, before it goes away! Microsoft has now published a download for Windows 7 SDK for .NET 4. It has the VC++ 2010 compiler. It can be a matter of days before the VC ++ 2008 compiler is totally unavailable. It is possible to build C and Fortran extensions for official Python 2.6/2.7 binaries on x86 using mingw. AFAIK, Microsoft's compiler is required for C++ or amd64 though. (Intel's compiler requires VS2008, which has now perished.) Remember Python on Windows will still require VS2008 for a long time. Just take a look at the recent Python 3 loath threads.
From: Thomas Jollans on 6 Jul 2010 12:21 On 07/06/2010 05:50 PM, sturlamolden wrote: > It is possible to build C and Fortran extensions for official Python > 2.6/2.7 binaries on x86 using mingw. AFAIK, Microsoft's compiler is > required for C++ or amd64 though. (Intel's compiler requires VS2008, > which has now perished.) 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. As for amd64 - I do not know if there is a mingw64 release for windows already. If there isn't, there should be ;-) But that doesn't really change anything: the express edition of Microsoft's VC++ doesn't include an amd64 compiler anyway, AFAIK. Also, VS2010 should work as well - doesn't it? > > Remember Python on Windows will still require VS2008 for a long time. > Just take a look at the recent Python 3 loath threads. >
From: sturlamolden on 6 Jul 2010 12:39 On 6 Jul, 18:00, "Alf P. Steinbach /Usenet" <alf.p.steinbach +use...(a)gmail.com> wrote: > There is no *technical* problem creating a compiler-independent C/C++ language > binding. I believe that Java's JNI works fine no matter what compiler you use, > although it's many many years since I've done JNI things. Similarly, Python > should IMHO just have a well defined compiler independent native code interface, > e.g. "PNI", or "pynacoin", the PYthon NAtive COde INterface :-) Yes but Python currently does not, due to dependency on VS2003 (2.5) or VS2008 (2.6, 2.7, 3.1) C and C++ runtime DLLs. It's not the binary interface that is the trouble, but CRT versioning. C++ is extra troublesome due to name mangling, standard runtime and exceptions. Here are the issues: C++: VS2010 - does not link with msvcp90.dll but msvcp100.dll. mingw - linkes statically with its own C++ library. Win32, ANSI C: VS2010 - does not link with msvcr90.dll but msvcr100.dll. mingw - ok for C if passed -lmsvcr90 on linking step Win64, ANSI C: VS2010 - does not link with msvcr90.dll but msvcr100.dll. mingw - missing import libraries (libmsvcr90.a and libpython26.a) Visual Studio 2008's C/C++ compiler is the only sane solution. It is still there so go get it if you don't already have a copy (I guess Alf does).
From: sturlamolden on 6 Jul 2010 12:49 On 6 Jul, 18:21, Thomas Jollans <tho...(a)jollans.com> wrote: > mingw gcc should work for building C++ extensions if it also works for C > extensions. No, it uses an incompatible statically linked C++ runtime. We need to use msvcp90.dll with Python 2.6/2.7. > As for amd64 - I do not know if there is a mingw64 release for windows > already. If there isn't, there should be ;-) There is. But it does not have an import library for msvcr90.dll. It's omitted from mingw-w64. Also libpython26.a is missing from Python on Windows 64. > Also, VS2010 should work as well - doesn't it? The problem with Microsoft's compilers is that they just let you pick between two CRTs (single- or multi-threaded). We need to specify the version number as well. So no, VS2010 will not work. (At least not without some ugly hacks.)
From: Christian Heimes on 6 Jul 2010 12:58
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. > 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. |