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: Christian Heimes on 6 Jul 2010 15:49 > That's nice to know, but I personally don't have an MSDN subscription. > Many scientists don't have access to development tools like VS2008. > Many hobby developers don't have access expensive MSDN subscriptions. > Many don't develop C personally, but just "needs a compiler" to build > an extension with distutils. And for all of us not subscribing to > MSDN, this is the only remaining source. I agree, the situation isn't ideal. I see if I can get in contact with Microsoft's open source team. Perhaps they can keep the download link to VS 2008 EE working. By the way lot's of universities participate in the MSDN Academy Alliance program. Students, scientists and employees of the university can get most MSDN packages.
From: casevh on 6 Jul 2010 15:52 On Jul 6, 9:21 am, Thomas Jollans <tho...(a)jollans.com> wrote: > 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. The original version of the Windows 7 SDK includes the command line version of the VS 2008 amd64 compiler. I've used it compile MPIR and GMPY successfully. The GMPY source includes a text file describing the build process using the SDK tools. casevh > > 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.- Hide quoted text - > > - Show quoted text -
From: sturlamolden on 6 Jul 2010 16:19 On 6 Jul, 21:49, Christian Heimes <li...(a)cheimes.de> wrote: > I agree, the situation isn't ideal. I see if I can get in contact with > Microsoft's open source team. Perhaps they can keep the download link to > VS 2008 EE working. It seems the MSDN subscription required to get VS 2008 costs one dollar less than $1200. So it does not fit within everyone's budget.
From: sturlamolden on 6 Jul 2010 16:49 On 6 Jul, 21:52, casevh <cas...(a)gmail.com> wrote: > On Jul 6, 9:21 am, Thomas Jollans <tho...(a)jollans.com> wrote: > > But that doesn't really > > change anything: the express edition of Microsoft's VC++ doesn't include > > an amd64 compiler anyway, AFAIK. See here: http://jenshuebel.wordpress.com/2009/02/12/visual-c-2008-express-edition-and-64-bit-targets/ The express edition can be used as is for x86 though (it might not have an optimizing compiler). It can also be used for C++, unlike g++ (at least VC++ is safer). > The original version of the Windows 7 SDK includes the command line > version of the VS 2008 amd64 compiler. C:\Program Files\Microsoft SDKs\Windows\v7.0>cl Microsoft (R) C/C++ Optimizing Compiler Version 15.00.30729.01 for x64 Copyright (C) Microsoft Corporation. All rights reserved. usage: cl [ option... ] filename... [ /link linkoption... ] C:\Program Files\Microsoft SDKs\Windows\v7.0> Need any more proof? :D Also note that the Windows 7 SDK can still be used with IDEs, like Qt Creator, KDEvelop (yes there is a Windows version), Eclipse, Visual Studio, and even Visual C++ Express (a little PITA for amd64, but possible too). I'm still fan of a tiny text editor for typing (Kate from KDE tends to be my favorite) and a Python script for building, though.
From: David Cournapeau on 6 Jul 2010 18:08
On Tue, Jul 6, 2010 at 6:00 PM, Alf P. Steinbach /Usenet <alf.p.steinbach+usenet(a)gmail.com> wrote: > * sturlamolden, on 06.07.2010 17: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. > > Perhaps this all for the good. > > There is no *technical* problem creating a compiler-independent C/C++ > language binding. It is quite hard, though, or would require changes in the API to be entirely safe. When I asked the question a few months ago to see if we could fix those issues once and for all for numpy, the most common answer I got was to pass all the related functions in a structure: http://stackoverflow.com/questions/1052491/c-runtime-objects-dll-boundaries. The problem is not compiler, but really C runtimes. By itself, the issues are not windows specific (using malloc from one C library and one free from another one is trouble everywhere), but on windows: - multiple C runtimes are *very* common on windows - many things which are runtime independent on unix are not on windows (file descriptor: AFAIK, a file descriptor as returned from open can be dealt with in any C runtime on unix) - the MS standard C library is clearly not a priority: win32 specific objects can be shared across runtimes, but standard C rarely can. - the recent manifest concept (which can improve or worsen the issues) is incredibly convoluted, and poorly documented (they expect you to use MS tool and not to try to understand how it works). David |