[ python-Bugs-870382 ] Mingw needs to use the same MSVC runtime as Python

[SourceForge.net]

Bugs item #870382, was opened at 2004-01-04 14:55
Message generated for change (Comment added) made by pmoore
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=870382&group_id=5470

Category: Distutils
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Moore (pmoore)
Assigned to: Martin v. Löwis (loewis)
Summary: Mingw needs to use the same MSVC runtime as Python

Initial Comment:
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).

----------------------------------------------------------------------

>Comment By: Paul Moore (pmoore)
Date: 2004-07-09 12:17

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

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2004-01-05 21:30

Message:
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.

----------------------------------------------------------------------

Comment By: Paul Moore (pmoore)
Date: 2004-01-04 23:01

Message:
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...

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2004-01-04 15:03

Message:
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.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=870382&group_id=5470