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

Alf P. Steinbach /Usenet alf.p.steinbach+usenet at gmail.com
Wed Jul 7 17:19:13 EDT 2010


* 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>



More information about the Python-list mailing list