RE: [Distutils] Compiling extensions with MingW32 / python.org binary
From: Michael Droettboom
I've come across a possible bug with --compiler=mingw32 and --compiler=cygwin support when using the standard python.org 2.3.3 .exe. (I do this so I can distribute binary installers that work with the standard Python distribution, but don't want to buy MS Visual Studio...)
I don't have a C extension handy to try at the moment, but I haven't had a problem in the past using mingw (--compiler=mingw32) and python.org python 2.3.3. Can you clarify what you are having problems with? Using python.org python with cygwin gcc (--compiler=cygwin)? If so, I have no experience with that, so I can't help (beyond saying that mingw works fine, so don't break that in the process of fixing the cygwin case!) Paul.
Moore, Paul wrote:
From: Michael Droettboom
I've come across a possible bug with --compiler=mingw32 and --compiler=cygwin support when using the standard python.org 2.3.3 .exe. (I do this so I can distribute binary installers that work with the standard Python distribution, but don't want to buy MS Visual Studio...)
I don't have a C extension handy to try at the moment, but I haven't had a problem in the past using mingw (--compiler=mingw32) and python.org python 2.3.3.
Can you clarify what you are having problems with? Using python.org python with cygwin gcc (--compiler=cygwin)? If so, I have no experience with that, so I can't help (beyond saying that mingw works fine, so don't break that in the process of fixing the cygwin case!)
I'm having problems with both --compiler=cygwin and --compiler=mingw32.
Michael Droettboom wrote:
Moore, Paul wrote:
From: Michael Droettboom
I've come across a possible bug with --compiler=mingw32 and --compiler=cygwin support when using the standard python.org 2.3.3 .exe. (I do this so I can distribute binary installers that work with the standard Python distribution, but don't want to buy MS Visual Studio...)
I don't have a C extension handy to try at the moment, but I haven't had a problem in the past using mingw (--compiler=mingw32) and python.org python 2.3.3.
Can you clarify what you are having problems with? Using python.org python with cygwin gcc (--compiler=cygwin)? If so, I have no experience with that, so I can't help (beyond saying that mingw works fine, so don't break that in the process of fixing the cygwin case!)
I'm having problems with both --compiler=cygwin and --compiler=mingw32.
Please check your environment: could be that distutils picks up an environment setting that changes gcc to cc. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 13 2004)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
M.-A. Lemburg wrote:
Michael Droettboom wrote:
Moore, Paul wrote:
From: Michael Droettboom
I've come across a possible bug with --compiler=mingw32 and --compiler=cygwin support when using the standard python.org 2.3.3 .exe. (I do this so I can distribute binary installers that work with the standard Python distribution, but don't want to buy MS Visual Studio...)
I don't have a C extension handy to try at the moment, but I haven't had a problem in the past using mingw (--compiler=mingw32) and python.org python 2.3.3.
Can you clarify what you are having problems with? Using python.org python with cygwin gcc (--compiler=cygwin)? If so, I have no experience with that, so I can't help (beyond saying that mingw works fine, so don't break that in the process of fixing the cygwin case!)
I'm having problems with both --compiler=cygwin and --compiler=mingw32.
Please check your environment: could be that distutils picks up an environment setting that changes gcc to cc.
Here's my os.environ (no mention of cc anywhere...): {'TMP': 'c:\\DOCUME~1\\MICHAE~1\\LOCALS~1\\Temp', 'TEXMF': '{/usr/share/lilypond /2.0.1,/usr/share/texmf}', 'COMPUTERNAME': 'MASTA-BOOM', 'USERDOMAIN': 'MASTA-BOOM', 'COMMONPROGRAMFILES': 'C:\\Program Files\\Common Files', 'PROCESSOR_IDENTIFIER': 'x86 Family 15 Model 2 Stepping 4, GenuineIntel', 'CVS_RSH': 'ssh', 'USER': 'Michael Droettboom', 'PROCESSOR_REVISION': '0204', 'PATH': 'C:\\cygwin\\usr\\local\\bin;C:\\cygwin\\bin;C:\\cygwin\\bin;c:\\PROGRA~1\\PYTHON23;C:\\cygwin\\us r\\X11R6\\bin', 'SYSTEMROOT': 'C:\\WINDOWS', 'PS1': '\\[\\033]0;\\w\\007\n\\033[32m\\]\\u@\\h \\[\\033[33m\\w\\033[0m\\]\n$ ', 'KDEHOME': '"C:\\Documents and Settings\\Michael Droettboom\\Application Data"', 'KDEDIR': 'C:\\cygwin\\opt\\kde3', 'TERM': 'cygwin', 'TEMP': 'c:\\DOCUME~1\\MICHAE~1\\LOCALS~1\\Temp', 'SHLVL': '1', 'PROCESSOR_ARCHITECTURE': 'x86', 'ALLUSERSPROFILE': 'C:\\Documents and Settings\\All Users', 'CLIENTNAME': 'Console', 'MANPATH': ':/usr/X11R6/man:/usr/ssl/man', 'HOMEPATH': '\\Documents and Settings\\Michael Droettboom', 'HOME': 'c:\\DOCUME~1\\MICHAE~1\\MYDOCU~1', 'USERNAME': 'Michael Droettboom', 'LOGONSERVER': '\\\\MASTA-BOOM', 'PROMPT': '$P$G', 'COMSPEC': 'C:\\WINDOWS\\system32\\cmd.exe', 'MAKE_MODE': 'unix', 'SESSIONNAME': 'Console', 'PATHEXT': '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH', '_': '/cygdrive/c/PROGRA~1/PYTHON23/python', 'WINDIR': 'C:\\WINDOWS', 'CYGWIN_ROOT': 'C:\\cygwin', 'APPDATA': 'C:\\Documents and Settings\\Michael Droettboom\\Application Data', 'HOMEDRIVE': 'C:', 'OLDPWD': '/cygdrive/c/DOCUME~1/MICHAE~1/MYDOCU~1/gamera', 'NUMBER_OF_PROCESSORS': '4', 'PWD': '/cygdrive/c/Program Files/python23/Lib/distutils', 'LTDL_LIBRARY_PATH': 'C:\\cygwin\\opt\\kde3\\lib;C:\\cygwin\\opt\\kde3\\lib\\kde3', 'PROCESSOR_LEVEL': '15', 'USERPROFILE': 'C:\\Documents and Settings\\Michael Droettboom', 'OS': 'Windows_NT', 'SYSTEMDRIVE': 'C:', 'PROGRAMFILES': 'C:\\Program Files'}
Michael Droettboom wrote:
M.-A. Lemburg wrote:
Michael Droettboom wrote:
Moore, Paul wrote:
From: Michael Droettboom
I've come across a possible bug with --compiler=mingw32 and --compiler=cygwin support when using the standard python.org 2.3.3 .exe. (I do this so I can distribute binary installers that work with the standard Python distribution, but don't want to buy MS Visual Studio...)
I don't have a C extension handy to try at the moment, but I haven't had a problem in the past using mingw (--compiler=mingw32) and python.org python 2.3.3.
Can you clarify what you are having problems with? Using python.org python with cygwin gcc (--compiler=cygwin)? If so, I have no experience with that, so I can't help (beyond saying that mingw works fine, so don't break that in the process of fixing the cygwin case!)
I'm having problems with both --compiler=cygwin and --compiler=mingw32.
Okay, the detail that I realise is important is that this is a C++ extension.
From unixccompiler.py (line 169 in Python 2.3.3): try: if target_desc == CCompiler.EXECUTABLE: linker = self.linker_exe[:] else: linker = self.linker_so[:] if target_lang == "c++" and self.compiler_cxx: #*** linker[0] = self.compiler_cxx[0] #*** self.spawn(linker + ld_args) except DistutilsExecError, msg: raise LinkError, msg Since target_lang == "c++", and self.compiler_cxx is defined in unixccompiler.py as "cc", but not overridden in cygwinccompiler.py (as compiler, compiler_so, linker_exe and linker_so are...) we end up with the command line having cc instead of gcc at the front. In the Python CVS history, it seems that the lines marked *** were added since the release22-maint branch, which explains why this used to work for me with Python 2.2. Under a Cygwin or Mingw32 build where Python was built with Cygwin, the symlink from cc to gcc works. However, "standard" Windows executables, such as the python.org interpreter can not follow Cygwin symlinks and it chokes. I seems that compiler_cxx should be defined as "gcc -mcygwin" and "gcc -mnocygwin" in cygwinccompiler.py. I have a patch -- not sure what the procedure is to submit it, however. Hope I'm on the right track... Mike
Michael Droettboom
Okay, the detail that I realise is important is that this is a C++ extension.
Yes, that's pretty important :-) I don't use C++, so I didn't see this.
I seems that compiler_cxx should be defined as "gcc -mcygwin" and "gcc -mnocygwin" in cygwinccompiler.py. I have a patch -- not sure what the procedure is to submit it, however.
The following works for me, for a trivial test: --- cygwinccompiler.py.orig 2003-04-14 13:51:26.000000000 +0100 +++ cygwinccompiler.py 2004-01-14 21:00:33.000000000 +0000 @@ -108,6 +108,7 @@ # XXX optimization, warnings etc. should be customizable. self.set_executables(compiler='gcc -mcygwin -O -Wall', compiler_so='gcc -mcygwin -mdll -O -Wall', + compiler_cxx='g++ -mcygwin -O -Wall', linker_exe='gcc -mcygwin', linker_so=('%s -mcygwin %s' % (self.linker_dll, shared_option))) @@ -295,6 +296,7 @@ self.set_executables(compiler='gcc -mno-cygwin -O -Wall', compiler_so='gcc -mno-cygwin -mdll -O -Wall', + compiler_cxx='g++ -mno-cygwin -O -Wall', linker_exe='gcc -mno-cygwin', linker_so='%s -mno-cygwin %s %s' % (self.linker_dll, shared_option, How does it compare with your patch? You should submit your patch to sourceforge. On www.python.org, there's a "bugs" link in the left hand sidebar, under the "Documentation" section. Thanks for persisting with this! Paul. -- This signature intentionally left blank
Paul Moore wrote:
Michael Droettboom
writes: Okay, the detail that I realise is important is that this is a C++ extension.
Yes, that's pretty important :-) I don't use C++, so I didn't see this.
I seems that compiler_cxx should be defined as "gcc -mcygwin" and "gcc -mnocygwin" in cygwinccompiler.py. I have a patch -- not sure what the procedure is to submit it, however.
The following works for me, for a trivial test:
--- cygwinccompiler.py.orig 2003-04-14 13:51:26.000000000 +0100 +++ cygwinccompiler.py 2004-01-14 21:00:33.000000000 +0000 @@ -108,6 +108,7 @@ # XXX optimization, warnings etc. should be customizable. self.set_executables(compiler='gcc -mcygwin -O -Wall', compiler_so='gcc -mcygwin -mdll -O -Wall', + compiler_cxx='g++ -mcygwin -O -Wall', linker_exe='gcc -mcygwin', linker_so=('%s -mcygwin %s' % (self.linker_dll, shared_option))) @@ -295,6 +296,7 @@
self.set_executables(compiler='gcc -mno-cygwin -O -Wall', compiler_so='gcc -mno-cygwin -mdll -O -Wall', + compiler_cxx='g++ -mno-cygwin -O -Wall', linker_exe='gcc -mno-cygwin', linker_so='%s -mno-cygwin %s %s' % (self.linker_dll, shared_option,
How does it compare with your patch?
That's exactly what I did (with the exception of the -O -Wall , which isn't in the version I have here.)
You should submit your patch to sourceforge. On www.python.org, there's a "bugs" link in the left hand sidebar, under the "Documentation" section.
Thanks for persisting with this!
No problem.
Paul.
Michael Droettboom
Please check your environment: could be that distutils picks up an environment setting that changes gcc to cc.
Here's my os.environ (no mention of cc anywhere...): [...]
Your PATH has cygwin in, but not mingw. Therefore, I wouldn't expect --compiler=mingw32 to work. I can't help with --compiler=cygwin, sorry. Paul. -- This signature intentionally left blank
participants (4)
-
M.-A. Lemburg
-
Michael Droettboom
-
Moore, Paul
-
Paul Moore