search

coolcoolad / pythonxy

Automatically exported from code.google.com/p/pythonxy
0 stars 0 forks source link

Update MinGW with MSYS #299

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?

Please use labels and text to provide additional information.

Original issue reported on code.google.com by grizzly.nyo on 15 Sep 2011 at 6:20

GoogleCodeExporter commented 9 years ago

Original comment by grizzly.nyo on 15 Sep 2011 at 7:26

GoogleCodeExporter commented 9 years ago 
mingw-gcc 4.6.1 no longer supports -mno-cygwin command line option. This breaks 
mingw32 compiler option in distutils.

Original comment by grizzly.nyo on 5 Oct 2011 at 7:28

GoogleCodeExporter commented 9 years ago

Original comment by grizzly.nyo on 17 Oct 2011 at 9:21

GoogleCodeExporter commented 9 years ago

Original comment by grizzly.nyo on 31 Jan 2012 at 8:58

GoogleCodeExporter commented 9 years ago

Original comment by grizzly.nyo on 5 Mar 2012 at 8:44

GoogleCodeExporter commented 9 years ago

Original comment by grizzly.nyo on 5 Mar 2012 at 8:45

GoogleCodeExporter commented 9 years ago 
IMHO, if distutils does not cope with newer mingw compilers, it is enough to 
patch it. The patch is available at  https://gist.github.com/geertj/4466320 as 
discussed in http://bugs.python.org/issue12641.  And the mingw environment 
should then be updated to a recent msys asap.

Note that the patch mentioned above works perfectly and the distutils developer 
are not yet applying it just because of two reasons. First of all they 
personally use the MSVC and not mingw compiler in windows, so it is not their 
top priority. Secondly and most important they are too scared of breaking 
distutils for users that might still be using old mingw (and they have strict 
policies about this). For this reason they are waiting for a reliable heuristic 
to be developed to find out if the -mno-cygwin parameter is needed or not 
before changing anything.

However, for python(x,y) the situation is completely different. Python(x,y) is 
in full control of its mingw since it ships mingw itself! There is no risk of 
breaking anything, since there is a single version of mingw to support.

Note that the current situation is conversely quite unsatisfactory. Whenever 
you need to compile an extension module which comes from unix, you may need to 
compile libraries too. These typically have makefiles that rely on some basic 
shell functions, so that they cannot be compiled in the current mingw 
environment. However, if one installs msys to compile them, then there is a 
mismatch in the gcc versions (4.5.x in current python(x,y), 4.7.x in current 
msys), which results in incompatible libgfortran, etc. 

Note that once distutils is patched, python(x,y) could even avoid shipping 
mingw alltogether, letting the users install and rely on the official msys, or 
could incapsulate and install the official msys itself.  As a positive side 
effect of relying on the official msys, this would also enable python(x,y) 
users to rely on the msys migw-get command to gather whatever msys extension 
facility they need.

Original comment by sergio.c...@gmail.com on 3 May 2013 at 5:49

GoogleCodeExporter commented 9 years ago 
since MS put out Visual Studio for Python 2.7 MingW is no longer an interesting 
option.

Original comment by grizzly.nyo on 10 Oct 2014 at 7:42