DLL-building griefs

[Robert Kern]

In article <mailman.972841524.9374.python-list at python.org>, "Niki Spahiev"
<spahievi at vega.bg> wrote:

> 29.10.2000, 15:08:07, Will Ware wrote:
> 
> WW> I'm trying to build a DLL (previously using Cygwin, now using Mingw)
> WW> for a Python module. My batch file looks like this:
> 
> WW> gcc -Ic:\Python20\Include -c foo.c echo EXPORTS >> foo.def WW> nm
> foo.o | grep " T _" | sed "s/.* T _//" >> foo.def WW> dllwrap --def
> foo.def --base-file foo.base --output-exp foo.exp \ WW>    --dllname
> foo.dll foo.o
> 
> WW> During the execution of dllwrap.exe, I get complaints that various
> WW> functions are undefined: PyArg_ParseTuple, Py_BuildValue, and WW>
> Py_InitModule4. As a result, the DLL never gets built.
> 
> WW> My experience with Unix while building .so files has been that the
> WW> linker is willing to assume that these references would be resolved
> WW> when the .so file was invoked by, say, being imported by Python. WW>
> Is it possible for references to remain unresolved during the build WW>
> process in Windows, or is this a fatal flaw in everything Windows-ish?
> 
> These are in pythonXX.dll so you should include puthonXX.lib for linker
> to be happy.

Well, not quite. You need to create an import library for python20.dll . 
python20.lib is the MSVC import library, but you need a mingw32 import 
library. Someone said that the script I provided for getting the symbols
from python15.lib and making the DEF file for the 1.5.2 import library
didn't catch all of the symbols from python20.lib . He tried the "hacked"
version of pexports (available from my Starship cabin) and got it to
work.

Some of the Python 2.0 headers may need to be patched like the 1.5.2
headers were patched by Paul Sokolovsky.

Good luck.

-- 
Robert Kern
kern at caltech.edu

"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."