Clarifications on compiling for Windows
peteshinners
my information about compiling Python and Python extensions for
Windows is correct. I'm really only experienced with this on the Linux
side of things.
First of all, is the Windows FAQ fairly up to date? Should people be
referring to section 6 if they are going to build an application with
an embedded Python interpreter?
http://www.python.org/doc/faq/windows/#how-can-i-embed-python-into-a-windows-application
If I understand correctly, compiled extensions for Python on Windows
should match the compiler that was used to build the interpreter
itself? Is there a list somewhere that shows which version of msvc was
used to compile the recent Python binaries?
Thank you for feedback. I definitely want to make sure I have this
correct before telling anybody else?
Mensanator
> My presentation for Pycon is coming together, but I need to make sure
> my information about compiling Python and Python extensions for
> Windows is correct. I'm really only experienced with this on the Linux
> side of things.
>
> First of all, is the Windows FAQ fairly up to date? Should people be
> referring to section 6 if they are going to build an application with
>
> If I understand correctly, compiled extensions for Python on Windows
> should match the compiler that was used to build the interpreter
> itself? Is there a list somewhere that shows which version of msvc was
> used to compile the recent Python binaries?
>
> Thank you for feedback. I definitely want to make sure I have this
> correct before telling anybody else?
You aren't going to try it?
Jason Scheirer
At a high level: YES. Avoid FILE* and you are golden on Windows. Works
like a charm.
MSVC 2008 works for 2.6 with the least effort (I strongly recommend
having it installed as that's what the build uses). If you have VS2008
you will have no problem whatsoever with setup.py install, even with C
extensions. I'd like to verify the same with earlier versions of VS
but I can't. MinGW works, too, but with slightly more effort: there
are some command line arguments you have to issue setup.py to know how
to use/where the MinGW compiler is.
Martin v. Loewis
Fairly, yes.
> Should people be
> referring to section 6 if they are going to build an application with
> an embedded Python interpreter?
I think that's very selective in its view of problems - why would I
be using SWIG, for example? (yet there are three issues dedicated to
SWIG in this section)
pythonNN.dll is not in \windows\system, but in system32 or winsxs.
pythonNN.lib is *not* a static library, but (as the text then notes)
an import library. So even if you link with pythonNN.lib, you *still*
need pythonNN.dll at run-time (what is discussed as a drawback of
dynamic linking). Of course, it might be possible to build a static
library out of Python (which then still might be called pythonNN.lib).
IMO, it should be possible to link Python into the executable (at
the expense of not supporting dynamic loading of extension modules
anymore).
> If I understand correctly, compiled extensions for Python on Windows
> should match the compiler that was used to build the interpreter
> itself? Is there a list somewhere that shows which version of msvc was
> used to compile the recent Python binaries?
See PCbuild/readme.txt of the respective Python release.
2.3: VC 6
2.4, 2.5: VC 7.1 / VS .NET 2003
2.6, 3.1: VC 9 / VS 2008
Regards,
Martin