The last couple of weeks I’ve mostly been coding on pyshapelib, that’s a small Python wrapper around shapelib, a C++ library to read ESRI shapefiles. It is originally written by Bernhard Herzog and is now maintained as part of Thuban, an open source interactive geographic data viewer. My contribution to pyshapelib is rewriting it to use hand-crafted Python bindings instead of SWIG generated ones, to support shapefiles with height (Z) or measurement (M) information, and to have better support for Unicode strings.
Until now it’s been quite interesting. I’ve learnt some new things about writing Python extension modules, for example that
METH_VARARGS functions do not take keyword arguments (something we assumed otherwise in the Lass Python API =) (update: it seems we’ve gotten that right after all). But the best surprise was this one:
mixing msvcr71.dll and msvcr80.dll can be really inauspicious
I’m not yet sure what exactly is going on, but when I tried to import my freshly built
wxproj (part of Thuban) in Python,
dynload_win.c failed resulting in a nice error message in the style of …
from wxproj import point_in_polygon_shape, shape_centroid ImportError: DLL load failed: A dynamic link library (DLL) initialization routine failed.
… and a nice message box:
It’s always nice to get the advice to contact yourself for more information, it’s so helpful =)
wxproj.pyd in Dependency Walker revealed that
wxproj.pyd was dependent on both
wxmsw26uh_vc.dll of wxPython 2.6) and
proj.dll of PROJ.4).
wxmsw26uh_vc.dll came straight out of an installer, but
proj.dll I have compiled myself.
From there, it was easy guess work. I replaced
proj.dll with a version compiled with VC7.1, and the problems mysteriously vanished.
Thing learnt: when building Thuban yourself, strictly use DLLs built with VC7.1 =)
It still makes me wonder though. I’ve compiled extension modules with VC8 before, and I’ve never encountered this problem before. And yet, they all must have been indirectly dependent on
python24.dll (Python 2.4 is compiled with VC7.1). So why is it complaining in
wxproj‘s case only?
Perhaps to be continued …
proj_i.lib: $(LIBOBJ) link /debug /dll /def:proj.def /out:$(PROJ_DLL) \\ /implib:proj_i.lib $(LIBOBJ) if exist $(PROJ_DLL).manifest mt.exe -manifest \\ $(PROJ_DLL).manifest -outputresource:$(PROJ_DLL);2
A ticket has been submitted to PROJ.4’s BugZilla.