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

[Anonymous]

Originally created by: j...@coderforlife.com

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

[Anonymous]

Originally posted by: pierre.raybaut

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

[Anonymous]

Originally posted by: j...@coderforlife.com

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.

[Anonymous]

Originally posted by: pierre.raybaut

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

Summary: Include MinGW 64-bit in the version based on Python 2.7 64bit
Labels: -Type-Defect -Priority-Medium Type-Enhancement Priority-Low
Status: Accepted

[Anonymous]

Originally posted by: VanBoxem...@gmail.com

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