Download Microsoft C/C++ compiler for use with Python 2.6/2.7ASAP
in [Python]
|
Prev: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
Next: re.sub unexpected behaviour
From: Alf P. Steinbach /Usenet on 6 Jul 2010 12:00 * 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. 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 :-) Cheers, - Alf -- blog at <url: http://alfps.wordpress.com>
From: Martin P. Hellwig on 6 Jul 2010 13:46 On 07/06/10 16:50, sturlamolden wrote: > > Just a little reminder: > > Microsoft has withdrawn VS2008 in favor of VS2010. The express version > is also unavailable for download.>:(( <cut> Public download that is, people like me who have a MSDN subscription can still download old versions like Visual Studio 2005. So I would say that there is no particular hurry. I would think that everyone really serious about MS development with MS tools should get an MSDN subscription anyway, it saves you a lot of money in the long run. -- mph
From: Alf P. Steinbach /Usenet on 7 Jul 2010 17:19 * Christian Heimes, on 07.07.2010 22:47: >> The main problem that the required MSVC redistributables are not necessarily >> present on the end user's system. > > It's not a problem for Python anymore. It took a while to sort all > problems out. Martin and other developers have successfully figured out > how to install the CRT for system wide and local user installations. A > system wide installation installs the CRT in the side by side cache > (WinSxS). A local installation keeps the msvcrt90.dll and the > Microsoft.VC90.CRT.manifest next to the python.exe. Python extensions no > longer embed a manifest so they share the CRT from the python.exe process. > > In order to ship a standalone exe you have to keep the CRT next to your > exe. This should work for py2exe binaries as well. At our company we > install our application stack entirely from subversion including Python > 2.6.5, Sun JRE and lots of other stuff. This works perfectly fine for us > even for servers without the MSVCRT redistributable. I think you're talking about a different problem. The CRT installed along with CPython works for extensions using the MSVC 9.0 CRT. However developing an extension with MSVC 10 the extension will use the 10.0 CRT, which is not necessarily present on the end user's system. As I see it there are five solutions with different trade-offs: A Already having Visual Studio 2008 (MSVC 9.0), or coughing up the money for an MSDN subscription, or visiting trade shows, so as to obtain that compiler version. -> Not an option for everybody. B Linking the CRT statically. -> Increased size, problems with CRT state such as file descriptors. C Linking the CRT dynamically and bundling the MSVC redistributables with the extension. -> Even more increased size for the download, but smaller total footprint for extensions in sum; same CRT state problems. D Linking the CRT dynamically and providing an optional download and install of the redistributables if they're not present. This would best be done with some support from the Python installation machinery. -> Small nice size for extensions, still same CRT state problems. E As D + a new compiler-independent native code interface that does not carry dependencies on CRT state such as file descriptors, like JNI. -> Really huge effort, and cannot be applied until some new Python version. And I think the clue here is that the CRT state problems can be avoided by careful coding. Hence, for those who cannot do A I think B is a realistic practical option, and D would be nice... Cheers, - Alf -- blog at <url: http://alfps.wordpress.com>
From: Alf P. Steinbach /Usenet on 7 Jul 2010 17:40
* Alf P. Steinbach /Usenet, on 07.07.2010 23:19: > > However developing an extension with MSVC 10 the extension will use the > 10.0 CRT, which is not necessarily present on the end user's system. > > As I see it there are five solutions with different trade-offs: > > A Already having Visual Studio 2008 (MSVC 9.0), or coughing up the > money for an MSDN subscription, or visiting trade shows, so as to > obtain that compiler version. > -> Not an option for everybody. > > B Linking the CRT statically. > -> Increased size, problems with CRT state such as file descriptors. > > C Linking the CRT dynamically and bundling the MSVC redistributables > with the extension. > -> Even more increased size for the download, but smaller total > footprint for extensions in sum; same CRT state problems. > > D Linking the CRT dynamically and providing an optional download and > install of the redistributables if they're not present. This would > best be done with some support from the Python installation machinery. > -> Small nice size for extensions, still same CRT state problems. > > E As D + a new compiler-independent native code interface that > does not carry dependencies on CRT state such as file descriptors, like > JNI. > -> Really huge effort, and cannot be applied until some new Python version. > > And I think the clue here is that the CRT state problems can be avoided > by careful coding. > > Hence, for those who cannot do A I think B is a realistic practical > option, and D would be nice... Wait... F Possibly, as the docs say, "Developer Studio will throw in a lot of import libraries that you do not really need, adding about 100K to your executable. To get rid of them, use the Project Settings dialog, Link tab, to specify ignore default libraries. Add the correct msvcrtxx.lib to the list of libraries." Can anyone confirm whether this works in practice with MSVC 10? Cheers, - Alf -- blog at <url: http://alfps.wordpress.com> |