Mingw needs to use the same MSVC runtime as Python

[pfmoore]

BPO	870382
Nosy	@loewis, @theller, @pfmoore
Files	cygwinccompiler.patch: Patch revised for 2.4a1

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/loewis'
closed_at = <Date 2004-08-03.12:42:14.000>
created_at = <Date 2004-01-04.14:55:30.000>
labels = ['library']
title = 'Mingw needs to use the same MSVC runtime as Python'
updated_at = <Date 2004-08-03.12:42:14.000>
user = 'https://github.com/pfmoore'

bugs.python.org fields:

activity = <Date 2004-08-03.12:42:14.000>
actor = 'loewis'
assignee = 'loewis'
closed = True
closed_date = None
closer = None
components = ['Distutils']
creation = <Date 2004-01-04.14:55:30.000>
creator = 'paul.moore'
dependencies = []
files = ['1156']
hgrepos = []
issue_num = 870382
keywords = []
message_count = 9.0
messages = ['19528', '19529', '19530', '19531', '19532', '19533', '19534', '19535', '19536']
nosy_count = 4.0
nosy_names = ['loewis', 'theller', 'paul.moore', 'anadelonbrin']
pr_nums = []
priority = 'high'
resolution = 'accepted'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue870382'
versions = ['Python 2.4']

[pfmoore]

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

[loewis]

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.

[pfmoore]

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

[loewis]

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.

[pfmoore]

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

[anadelonbrin]

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

[theller]

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.

[pfmoore]

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

[loewis]

Logged In: YES
user_id=21627

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