In article <053e01bf7180$bdee8020$4500a8c0@thomasnotebook>, Thomas
Heller
Yes, you are right of course. ...
being right doesn't help. The proper thing to do is somehow to get the right value for .pyds and or .dlls Greg does the higher level give any indication whether this is a python only thing or a normal dll?
....
From the MSDN docs [deleted]
I know this stuff (or at least I can read it in my msdn). The problem is: The linker generates an .exp and .lib file for every python extension built. Should msvccompiler.py delete these, or should install_ext delete them? Or should install_ext only copy the .pyd files instead of the whole tree?
As I understand it the .exp files are only needed when we want to do complicated (2 stage) linking a dll imports from and exports to another.
We could try and use /Z7 type debugging instead of /Zi
/Z7 C 7.0- Compatible Produces an .OBJ file and an .EXE file containing line numbers and full symbolic debugging information for use with the debugger. The symbolic debugging information includes the names and types of variables, as well as functions and line numbers.
Is it true that /Zi to the compiler and /pdb:None to the linker does the same as /Z7 to the compiler? I'm not sure...
Note that according to the standard we need to do stuff like using the _d versions of dll/pyd names for our link. At least for python15.lib and pyton15_d.lib there is some magic in config.h, so this is automatic. Works also for /D_DEBUG. We should drop the line self.add_library ( "python" + sys.version[0] + sys.version[2] ) in msvccompiler.py.
Thomas ...
You do cl -c -Z7 dingo.c .... link dingo.obj ...other.obj /incremental:no /pdb:NONE /debug /debugtype:cv /export:initdingo /out:dingo.pyd and no pdb file. I checked and it seems as though this results in files that can still be debugged provided you can find the .c files. the python_d.lib needs to be used in the link phase. -- Robin Becker