Using GNU C complier as the "default" windows complier

[kern at temp1.caltech.edu]

In article <4D0A23B3F74DD111ACCD00805F31D8100DB9151B at RED-MSG-50>, Bill Tutt <billtut at microsoft.com> writes:
> cygwin isn't thread safe at this moment in time.
> If anything, Python should be compiled using mingw32 instead of cygwin.
> Esp, in order to get the Win32 extensions to be useful.
> 
> However.... I have no idea if the Win32 extensions actually can be compiled
> successfully using mingw32 as a substantial portion of them are C++, and
> even if they could be compiled, there would be binary incompatability
> problems due to using C++. (C++ mangling is different for all C++
> compilers...)

C extensions work fine when compiled with mingw32 as long as you patch the headers 
slightly.  I have compiled M.A. Lemburg's C++ mxCrypto extensions with mingw32, and 
they seem to work fine.  LLNL's CXX doesn't run the last time I tried, but this may
be a problem with the options I used and not a fundamental incompatibility.

I have not had the opportunity to try GCC 2.95.2 yet.

> So given those two things, and neither Mark, I, or anybody
> else atm seems to care enough to bother trying to see if it'll work. The
> binary compatability problem is the biggest problem though. If a MSVC
> compiled Python install can't make use of a mingw32 Win32 extension DLL (or
> vice versa) then even bothering with trying becomes counter productive.

MSVC Python can use mingw32 extensions if the extensions are compiled properly.
See http://starship.python.net/crew/kernr/mingw32/Notes.html for instructions.
Paul Sokolovsky has patched the Python interpreter to compile with mingw32.  The 
build process still needs work, but the base is there.  http://www.is.lg.ua/~paul/devel

> (unless your willing to invest time in submitting changes to the source code
> to remove the C++ mangling issues) i.e. Turn all exported C++ objects into
> COM objects or something so you can just use COM vtbls to communicate.
> Needless to say, thats a lot of work that I'd rather not do. (I expect Mark
> won't be to gung ho to do that work either... :) )
> 
> Bill

[piggybacking below]

> > -----Original Message-----
> > From: Werner Fouche [mailto:wfouche at mindspring.com]
> > Sent: Wednesday, November 10, 1999 3:59 AM
> > To: python-list at python.org
> > Subject: Re: Using GNU C complier as the "default" windows complier
> > 
> > 
> > 
> > "Mike Callahan" <mcalla at home.com> wrote in message
> > news:ma4W3.7794$Ur4.223420 at news.rdc1.tn.home.com...
> > > This a question from a newbie but I was thinking...why 
> > doesn't the default
> > > Python code for windows use the GNU C complier for windows 
> > instead of the
> > MS
> > > complier. Would it be possible to distribute the GNU 
> > package along with
> > the
> > > Python package and thus make it easier to compile, extend, and embed
> > Python,
> > > use freeze, etc? I know it would take some work, but it 
> > seems it would
> > make
> > > windows Python a lot more like unix Python. Just a thought.

Bad idea.  Cygwin is huge, and anyone who needs it can get it herself.  Cygwin
alone is not the best compiler to use since it goes through a POSIX emulation
layer that slows things down.  mingw32 would be better since it uses MSVCRT.dll 
as its C runtime library (when properly configured).  However, as Bill mentioned,
C++ issues still would have to be worked out.

Here's how things stand as I can see:

  1) mingw32 extensions run on MSVC Python.
  2) The Python interpreter can be compiled with mingw32.
  3) C++ support is still iffy.
  4) freeze will probably work with mingw32, but I've never heard of anyone trying.
  5) Embedding?  Who knows?
  6) Use Cygwin for tools and not the compiler.

> > I had the same idea on the weekend. So I installed Cygwin
> > (http://www.cygnus.com/cygwin) on my NT system and after running
> > "./configure" got Python to compile and run. However, I could 
> > not get Python
> > threads to work.

Cygwin proper is not threadsafe.  mingw32 can be.

Robert Kern
kern at caltech.edu