Python 2.4 is now built with MSVC 7.1, which uses a 
new MSVC runtime library.

Extension DLLs should be built to use the same runtime 
DLL as Python itself (although it has not been possible 
to find a real-world example where not doing so causes 
a problem...)

The attached patch adds the appropriate -l flag to the 
link, based on the MSVC version reported in sys.version. 
(This has only been tested with a Python built with 
MSVC 7.1, the version number used for MSVC 7.0 is 
based on verbal reports only).

Logged In: YES 
user_id=21627

Could you add some kind of assertion to detect the case that
an entirely different compiler version is used? It would be
best if it gets the case of using MSVC6 right, and gives up
if some other compiler version is detected (I can't
determine os.version for the VC6 case right now, but Python
2.3 is built with it).

Apart from that, the patch looks good.

Logged In: YES 
user_id=113328

What about Python built with mingw? I don't think that's 
possible right now, but I'd expect people to work on it. And 
I've no idea what sys.version for that would be.

The only real cases are likely to be MSVC 7.1 (Python 2.4, 
binary dist), MSVC 6 (Python <= 2.3, binary dist) and hand-
built Python versions. The patch does the right thing for all 
the binary distributions, which are the ones where the user 
can't be assumed to know how to hack things to make them 
work.

For hand-built versions, the user can do "python setup.py 
build_ext --compiler=mingw32 -l msvcr71" (or whatever) to 
manually specify the runtime to use. Leaving the default as 
msvcrt (the CRT that comes with the OS, and is default for 
mingw) seems right - and better than aborting (particularly as 
I'm not sure how to check whether there's an -l option for 
the CRT specified by the user).

The best I could do is effectively to force build_ext to fail 
unless Python was built with MSVC, which seems unhelpful...

Logged In: YES 
user_id=21627

I'm primarily concerned about future
(unreleased-as-of-today) MSC versions; they likely have
version numbers like "1400"; linking msvcr71 to binaries
built with that compiler is likely wrong.

Not adding anything for gcc-built python versions is fine.

Logged In: YES 
user_id=113328

This is still an issue with 2.4a1. I'm not sure what the 
autodetection buys given that currently it's not possible to 
build extensions with 2.4a1 using mingw which are compatible 
with the stock python.org binary.

Can I suggest that this patch be applied, and issues around 
autodetection be deferred until there is a demonstrated need?

I've uploaded a revised patch for 2.4a1 (tested against the 
python.org supplied MSI).

Logged In: YES 
user_id=552329

FWIW, this patch works for me, and I'd definitely like to
see it in 2.4a2.  If the MSVC version isn't 1300 or 1310
(the theoretical 1400, for example), then it doesn't do
anything different to what 2.4a1 does, so it's hard to see
why that would be a problem (and with the patch applied,
there's a clear fix, just adding in the appropriate elif and
link - it's not like new versions come along all the time).

Logged In: YES 
user_id=11105

In principle, it would be possible to examine the import
table of pythonxy.dll, to find out to which msvcrXX.dll it
is linked to.

Logged In: YES 
user_id=113328

Can someone suggest what I need to do to get this patch, or
something similar, accepted? As things stand, the official
Python 2.4 build *does not support* building compatible
extensions with mingw, where 2.3 did.

I have no means of extending this patch to work with
user-built versions of Python - I don't currently have any
way of building Python for myself, to test any such change.
I don't object to someone making such an extension, but I
have seen no-one step forward.

I'm getting a little frustrated here. The arguments against
applying the patch seem largely theoretical (and outside my
expertise). I'd like to invoke "practicality beats purity"
here...

Logged In: YES 
user_id=21627

Thanks for the patch. Applied as cygwinccompiler.py 1.27.