Title: Distutils+mingw links agains msvcr90, while python27.dll is linked agains msvcrt
Type: Stage:
Components: Distutils Versions: Python 2.7
Status: open Resolution:
Dependencies: Superseder:
Assigned To: eric.araujo Nosy List: brian.curtin, catalin.iacob, eric.araujo, eudoxos, fratti, loewis, marmarek, mhammond, schmir, tarek
Priority: normal Keywords: patch

Created on 2012-11-14 13:34 by eudoxos, last changed 2013-11-02 20:49 by fratti.

File name Uploaded Description Edit
python-distutils-mingw32.patch marmarek, 2013-07-31 00:48
Messages (7)
msg175569 - (view) Author: Václav Šmilauer (eudoxos) * Date: 2012-11-14 13:34
Compiling an extension with --compiler=mingw32 with official python 2.7.3 distribution on Windows (64bit) leads to unusable result - crash on module load ("invalid access to memory").

The reasons is that Lib/distutils/ links the resulting .pyd file against msvcr90.dll (version is determined by version of MSVC used to build python itself), while python27.dll is linked against msvcrt.dll (shows the Dependency Walker). 

Based on my own experience (above) and MSDN docs,, loading 2 different runtimes is asking for trouble.

I raised this topic on distutils-sig, hoping for an explanation. Judging by the reaction, it is quite possibly historical relict which is no longer needed. This is also hinted at by comments at the beginning of Lib/distutils/

   "if you use a msvc compiled python version (1.5.2)"
   "mingw gcc 3.2/ld 2.13 works"

I am aware of distutils being frozen for new features (unless you want to call bugfix a new feature).
msg176371 - (view) Author: Catalin Iacob (catalin.iacob) * Date: 2012-11-25 16:47
Václav, are you sure about the official python27.dll being linked against msvcrt.dll? Maybe this is your own python27.dll compiled with MinGW?

I see the opposite: for both C:\windows\system32\python27.dll (64 bit) and c:\windows\SysWOW64\python27.dll (32 bit) from the Windows 2.7.3 installer, Dependency Walker shows they are linked against msvcr90.dll. This is probably also the reason why distutils links extensions against msvcr90.dll, exactly to avoid linking against 2 different CRTs.
msg176637 - (view) Author: Václav Šmilauer (eudoxos) * Date: 2012-11-29 11:19
I am sorry for the initial confusion. python27.dll is really linked against MSVCR90. Its path, though, is c:\windows\winsxs\amd64_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4940_none_08e4299fa83d7e3c\MSVCR90.DLL, and perhaps is a different one found at runtime?

Dependency walker also reveals, that python27.dll links against SHELL32, which itself links to MSVCRT.

PS I am using the offical build of 2.7.3 on Windows7 64bit.
msg176646 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2012-11-29 13:08
I think further investigation should require analysing the crash in a debugger. It may well be that the crash is completely unrelated to msvcrt.
msg176686 - (view) Author: Václav Šmilauer (eudoxos) * Date: 2012-11-30 13:50
I was having a compiled module consistently crash at import time when linking against msvcr90, and being imported fine when linked against msvcrt. I will try to investigate further with mingw folks.
msg193968 - (view) Author: Marek Marczykowski-Górecki (marmarek) * Date: 2013-07-31 00:48
I can confirm that when a module is linked against msvcr90, it crashes with "invalid access to memory". When removed that library from the linker options (that is - no explicit msvcr, in any version) - module worked perfectly.

Note that comment on (Minge32CComiler class) already says "no additional libraries needed", but 3 lines later it sets dll_libraries to msvcr90 (via get_msvcr). So just removing lines 336:338 works great. Patch attached. Any chances to get this fixed in the next python 2.7.x release?

My system is Windows 7 64bit, Python 2.7.5 64bit (from official msi installer)
msg201985 - (view) Author: Nicolas Frattaroli (fratti) Date: 2013-11-02 20:49
I had the same issue. It wouldn't just crash, it would crash sometimes, and not other times. About 50% of the time.

The solution to remove msvcr as suggested by Marek did work. I didn't apply his patch, however, because I'm using a MinGW64Compiler definition instead of the standard mingw32 one, which I got from a different distutils bug with a submitted patch that hasn't been reviewed yet.

Great work, gents.
Date User Action Args
2013-11-02 20:49:24frattisetnosy: + fratti
messages: + msg201985
2013-10-24 09:59:59tim.goldensetnosy: - tim.golden
2013-07-31 00:48:17marmareksetfiles: + python-distutils-mingw32.patch

nosy: + marmarek
messages: + msg193968

keywords: + patch
2012-11-30 13:50:27eudoxossetmessages: + msg176686
2012-11-29 13:08:39loewissetmessages: + msg176646
2012-11-29 11:20:00eudoxossetmessages: + msg176637
2012-11-25 16:47:48catalin.iacobsetnosy: + catalin.iacob
messages: + msg176371
2012-11-15 04:45:35eric.araujosetnosy: + loewis, mhammond, tim.golden, brian.curtin
2012-11-14 13:42:02schmirsetnosy: + schmir
2012-11-14 13:34:01eudoxoscreate