Martin Fiers added the comment:
This also affects our software. I agree with Dan (danmbox): I don't understand;
so many people depend on it and yet an out-of-the-box solution doesn't work.
I don't want to break the distutils package of our users because we use mingw.
Within one Python script, I managed to fix it using this before the setup call:
if isWindows():
"""
Fix bug in cygwinccompiler: removed -mno-cygwin. This is fixed in
cygwinccompiler_new.
We hacked the distutils.ccompiler : def new_compiler : It uses
sys.modules to fetch the compiler
By modifying the sys.modules, we can choose our own compiler version.
(this is a bug that's out there for quite some time)
"""
import cygwinccompiler_new
import distutils.cygwinccompiler
import sys
sys.modules["distutils.cygwinccompiler"] = cygwinccompiler_new
..if I then later run setup(...), it will use my new cygwinccompiler_new, that
has the '-mno-cygwin' line removed.
However, when you want to install new packages using pip from the command-line,
I cannot find a suitable fix (except if I would replace the
distutils.cygwinccompiler before pip'ing, then put it back). For afaik,
distutils cannot be virtualenv'ed, right? So we cannot even fix the issue in a
virtual environment.
If it is not possible to find out what version of gcc implemented it first;
can't you simply use a pragmatic solution and run
"gcc -mno-cygwin": if it gives an error, then remove the option. That would
need the least testing and would fix the issue.
----------
nosy: +Martin.Fiers
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue12641>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
