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

[sturlamolden]

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/...00-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.

 

[Alf P. Steinbach /Usenet]

* 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/...00-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

 

[Thomas Jollans]

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?

 

[sturlamolden]

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).

 

[sturlamolden]

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.)

 

[Thomas Jollans]

No, it uses an incompatible statically linked C++ runtime. We need to
use msvcp90.dll with Python 2.6/2.7.

Python is written in C. How does the C++ runtime enter into it?

 

[sturlamolden]

Okay, you need to be careful with FILE*s. But malloc and free? You'd
normally only alloc & free something within the same module, using the
same functions (ie not mixing PyMem_Malloc and malloc), would you not?

You have to be sure PyMem_Malloc is not an preprocessor alias for
malloc (I haven't chaecked).

In general, CRT objects cannot be shared across CRT boundaries.

Also remember the C and C++ standard libraries interact. g++ from
links statically with an incompatible C++ standard library (read: it
will segfault, it's just a question of when).

Coming from a system where I can generally rely on the system gcc to
work for everything, I may be a bit naïve wrt certain questions ;-)

On sane operating systems you generally have one version of libc
installed.

Windows did this too (msvcrt.dll) up to the VS2003 release, which came
with msvcr71.dll in addition. Since then, M$ (pronounced Megadollar
Corp.) have published msvcr80.dll, msvcr90.dll, and msvcr100.dll (and
corresponding C++ versions) to annoy C and C++ developers into
converting to C# .NET. (And yes, programs using third-party DLL and
OCX components become unstable from this. You have to check each DLL/
OCX you use, and each DLL used by each DLL, etc. How fun...)

 

[sturlamolden]

Python is written in C. How does the C++ runtime enter into it?

The C and C++ runtimes interact (e.g. stdlib.h and <iostream>), malloc
and new, etc. With g++ you have a C++ standard library compiled
against msvcrt.dll, whereas Python is using msvcr90.dll.

We can use the C++ runtime msvcp90.dll used by VC++ 2008, but this DLL
is binary incompatible with g++ (GNU uses a different ABI for C++).

 

[Martin P. Hellwig]

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.

 

[Robert Kern]

I downloaded the ISO, but it seems to be just a bit too big to fit on a CD!

This seems odd to me, has anyone else had this problem?

These days, ISOs are destined for DVD-Rs.

There are also utilities for mounting ISOs directly without burning them to a
physical disk. Here is a decent list:

http://www.techsupportalert.com/best-free-cd-emulator.htm

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

 

[sturlamolden]

Public download that is, people like me who have a MSDN subscription can
still download old versions like Visual Studio 2005.

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.

 

[David Robinow]

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.

Amazing!

 

[casevh]

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

 

[sturlamolden]

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.

 

[sturlamolden]

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?


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.

 

[David Cournapeau]

* sturlamolden, on 06.07.2010 17:50:

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

 

[Thomas Jollans]

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

I'm also rather sure that it's pretty much impossible to have multiple C
libraries in one process on UNIX, but it's obviously quite possible 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)

Are you telling me that file descriptors (it's a flippin int!) can't be
passed around universally on Windows??

Now Windows programming *really* scares me.

- the MS standard C library is clearly not a priority: win32 specific
objects can be shared across runtimes, but standard C rarely can.

And, as has already been said in this thread, this does not concern the
..net developer, or any developer that sticks to managed code, be it
..net, CPython, or something-else based.

- 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).

Cheers,

Thomas

 

[Martin v. Loewis]

- many things which are runtime independent on unix are not on

Are you telling me that file descriptors (it's a flippin int!) can't be
passed around universally on Windows??

There are really three things of concern here:
a) operating system file handles, of type HANDLE (which is an unsigned
32-bit value); they are not contiguous, and stdin/stdout/stderr may
have arbitrary numbers
b) C runtime file handles, of type int. They are contiguous, and
stdin/stdout/stderr are 0/1/2.
c) C FILE*.

OS handles can be passed around freely within a process; across
processes, they lose their meaning

It's the data of types b) and c) that cause problems: the CRT handle 4
means different things depending on what copy of the CRT is interpreting it.

It's worse with FILE*: passing a FILE* of one CRT to the fread()
implementation of a different CRT will cause a segfault.

And, as has already been said in this thread, this does not concern the
.net developer, or any developer that sticks to managed code, be it
.net, CPython, or something-else based.

Since when is CPython managed code?

Regards,
Martin

 

[sturlamolden]

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.

It should also be mentioned that the Windows 7 SDK includes
vcbuild.exe, so it can be used to compile Visual Studio 2008 projects
(I'm going to try Python).

 

[Martin P. Hellwig]

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.

Take in the cost of your operating system, and the ones you want to test
against, perhaps you also like to use office.
Although I am not a windows developer per se, I do use windows XP, 2000
2003, 2008, Vista and 7 for testing. I also use office for all those
clients who think that this is the only format.

1200 USD is actually quite cheap, but then again I didn't pay that
because I am either always been in an academic license (about 70 EUR a
year) or like now in a program for businesses who just start up (free
with my bank as supporting agent). When this 3 year subscription is over
I fall anyway in the cheaper renewals and if not I am sure that there is
some other brand new scheme like they did for the last decade.

Anyway, if you want to provide tools for platforms that are closed
source that means that there are costs for the developer and the client.
Although the cost for MS platforms are reasonable (as a developer and
you know you way around, that means go a couple of times to those free
MS events and it is quite likely you get an MSDN subscription for being
such a good loyal puppy), there are always costs.

If you don't like that better convince your target audience about an
open source operating system, whichever that may be.