Include MinGW 64-bit in the version based on Python 2.7 64bit

[GoogleCodeExporter]

Known problem about only including MinGW with the 32-bit version. You are 
probably using the "original" MinGW from mingw.org - they only have a 32-bit 
version, among some other problems. 

I consider that one defunct. I have been using MinGW-w64 now for quite some 
time with great success. They have compilers for both x86 and x86_64 (despite 
the 64 in the name, they support both - even cross compiling).

Original issue reported on code.google.com by j...@coderforlife.com on 2 Jan 2013 at 7:02

[GoogleCodeExporter]

I read that MinGW-w64 was not the best choice for building Python extensions:
http://wiki.cython.org/64BitCythonExtensionsOnWindows

Moreover, to be able to include another MinGW version, I need a complete "How 
to" like this one I've wrote:
http://code.google.com/p/winpython/source/browse/make.py#28
I don't have enought time to dig this further as it will concern only one of 
the fourth release of WinPython (only WinPython 2.7 64bit).

Original comment by pierre.raybaut on 2 Jan 2013 at 7:51

[GoogleCodeExporter]

Yes, there are some issues, but that information is also out of date.

MinGW-w64 is now stable (and has been for some time, although I can't find out 
when it became stable - presumably sometime after March 2011).

MinGW and MinGW-w64 have the same issues with runtime library compatibility 
with MSVC. It is rare, but does crop up in a few places. One thing that helps 
(slightly) is to have everything built to link directly against kernel32.dll 
(in MSVC this is done with "/MT" and in MinGW it is done with "-static-libgcc 
-static-libstdc++"). It doesn't solve all issues and makes slightly larger 
binaries, but it helps.

MinGW and MinGW-w64 have the same issues with MSVC++ compiled code. However, 
this only matters when using C++ linkage. You can always use C++ internally, as 
long as the functions being called are "extern c". I have tried to look more 
into the COM issues mentioned, and have not found much. As long as there are 
complete IDLs then there should be no problem. The problem comes up when the 
IDLs are missing.

So basically, MinGW-w64 is no worse than MinGW. No new problems will be 
introduced and the major problem solved is 64-bit support. Historically I have 
had other problems with MinGW, although they recently have been doing a lot of 
updates and may have fixed them.

The last issue you bring up is the biggest one for you. However, since 
MinGW-w64 is a fork of MinGW, they use a lot of the same layout. The most major 
thing that has changed is the download location.

All in all, I mainly wanted to bring this potential solution to your attention. 
I actually don't need it - I currently just compile my code myself and use 
ctypes... no Cython for now.

Original comment by j...@coderforlife.com on 2 Jan 2013 at 11:38

[GoogleCodeExporter]

Thanks for these detailed explanations.

I'll see when I can do something about it.
As I wrote above, this is not a top priority as it does only concern the 
version based on Python 2.7 64bit because AFAIK MinGW can't link with Visual 
C++ 2010 DLLs (Python 3.3 is built with VS2010).

Original comment by pierre.raybaut on 4 Jan 2013 at 1:41

• Changed title: Include MinGW 64-bit in the version based on Python 2.7 64bit
• Changed state: Accepted
• Added labels: Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

MinGW-w64 provides import libraries for the various msvcr* dll's. The "right" 
way to link with them is to modif GCC's spec file to not use msvcrt, but 
AFAICT, just adding -lmsvcr100 "just works".

Original comment by VanBoxem...@gmail.com on 18 Mar 2013 at 10:11