Open GoogleCodeExporter opened 9 years ago
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
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
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
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
Original issue reported on code.google.com by
j...@coderforlife.com
on 2 Jan 2013 at 7:02