From: John H. <jd...@gm...> - 2009-06-10 22:18:50
|
On Wed, Jun 10, 2009 at 4:41 PM, John Hunter<jd...@gm...> wrote: > Drop the tar.gz into release/win32 and then following the instructions > in release/win32/README.txt I should add one more detail here. distutils for python2.6 adds a dependency to MSVCR90.DLL, and Charlie has a distutils hack in release/win32/data/setupwin.py to try and banish the msvcr90.dll which is not on most systems; he sets the distutils dll_libraries to the empty list:: from distutils import cygwinccompiler try: # Python 2.6 # Replace the msvcr func to return an empty list cygwinccompiler.get_msvcr cygwinccompiler.get_msvcr = lambda: [] w/o this hack you will get a dll import error rather than a segfault. You can toggle the hack on and off by changing in the Makefile:: # on ${PYTHON} setupwin.py build_ext -c mingw32 -I ${PY_INCLUDE} -L ${PY_LINKER} bdist_wininst # off ${PYTHON} setup.py build_ext -c mingw32 -I ${PY_INCLUDE} -L ${PY_LINKER} bdist_wininst The problem is that the dll cannot be found on the system and apparently the right solution is to include it in a framework as described by David in the link I posted http://cournape.wordpress.com/2008/09/02/how-to-embed-a-manifest-into-a-dll-with-mingw-tools-only/ but I think this is something of a red herring because w/ Charlie's hack _png links against MSVCRT.DLL rather than MSVCR90.DLL but still segfaults (only on python2.6) on the png_write_info call. I also tried forcing 'msvcr71' in the distutils hack which is what python2.5 usesbut to no avail. When I said I wasted a lot of time chasing down false leads, most of that was spent on trying various versions of mpl, numpy, distutils, and the distutils MSVCR hacks, but in the end none of it mattered. But for the record I am including some notes I took while experimenting with different things. When I write below Interestingly, depwalker can find the DLL where PYTHON26.DLL depends on, pointing to C:\WINDOWS\WinSxS.VC90.CRT_1fgobbledygook on my box, but cannot find it where _PNG.PYD depends on it. this was before I discovered David's essay on side-by-side assemblies which explains why the linker finds python's MSVCR90.DLL but not _pngs. What it doesn't explain is why w/ Charlie's hack, when we link against MSVCRT.DLL or MSVCR71.DLL, png is still segfaulting, and I think the answer there is what I pointed to in my first post, the broken time support in mingw MSVCR90.DLL. Support for this is in my note below:: This time it finds it, but two of the functions are colored red indicating a problem: _fstati64 and gmtime. Notes on the _png segfault and the MSVCR hacks ====================================== I have been working on the windows installers for mpl 98.5.3. I am able to build for python2.5 w/o problems, but when building for python2.6, I get an DLL local error on any extension code cd matplotlib-0.98.5.3/build/lib.win32-2.6/matplotlib > /c/python26/python -c 'import _png' Traceback (most recent call last): File "<string>", line 1, in <module> ImportError: DLL load failed: The specified procedure could not be found. when I open _PNG.PYD this file in dependency walker, I see a dependency on MSVCR90.DLL which is flagged with a question mark "Error opening file. The system cannot find the file specified". All the *.PYD files have this dependency, including the numpy pyd files, but most of them have it buried under a PYTHON26.DLL dependency, and _PNG.PYD has it as a direct dependency (top level). Interestingly, depwalker can find the DLL where PYTHON26.DLL depends on, pointing to C:\WINDOWS\WinSxS.VC90.CRT_1fgobbledygook on my box, but cannot find it where _PNG.PYD depends on it. When I look at _PNG.PYD for python2.5 (which is working fine and I've uploaded the installers) I see a dependency for MSVCR71.DLL located in C:/windows/system32, and the functions it provides include fclose, fopen, putc, etc. which libpng apparently needs for file I/O. As mentioned above, my system *does* have MSVCR90.DLL deep in C:\WINDOWS\WinSxS.VC90.CRT_1fgobbledygook, and when I move it into C:\windows\system32 and then reopen _png.pyd in depdendency walker, I still get an error. This time it finds it, but two of the functions are colored red indicating a problem: _fstati64 and gmtime. Charlie has a distutils hack in release/win32/data/setupwin.py. Wen I build the installer using the hacked distutils I can load the DLL file in mpl either by importing matplotlib._png or in dependency walker. In depwalker, the msvcrt90.DLL is replaced by MSVCRT.DLL at the top level _PNG.PYD dependency, but the MSVCR90.DLL is still buried deep under PYTHON26.DLL. Unfortunately, use of this module triggers a segfault. |