2

I'm distributing a Windows application that embeds Python 2.7 (technique: include python27.dll + 'Python27' directory with DLLs and Lib folder, alongside my .exe). I'm also including a custom Python package that uses C extensions (.pyd files which are basically DLLs).

I'm aware that I need to have version 9.0.21022.8 of msvcr90.dll and the associated manifest. I'm able to put msvcr90.dll + manifest alongside my .exe file and I have that working, no problems. But in order to use my custom Python package, I'm finding that I also need to include msvcr90.dll + manifest at the same level as the package's .pyd files (application crashes during PyImport_ImportModule if they're not there). I don't understand why the .pyds are not able to "see" the msvcr90.dll that is further up the tree.

I'm aware that I can (probably) skirt this by running the MS Visual C Redistributable package on the destination machine...this essentially installs the MSVCR DLL + manifest so it is available system-wide. But I do not want to require my users to run that, nor do I want to try to mess with trying to install it in the correct location and deal with versioning, etc. myself.

djangodude
  • 5,362
  • 3
  • 27
  • 39
  • 1
    Try Python 2.7.3 and recompile all problematic extensions. This might have been fixed in http://bugs.python.org/issue4120 and http://bugs.python.org/issue7833, but not all extension modules are up to date. – cgohlke Sep 26 '12 at 19:48
  • 1
    This does the trick for me; I can now just include a single msvc*.dll + manifest at the same level as python27.dll and it works. Consider moving your comment to an answer...I'll accept it, if you want the rep +. If not: please accept my thanks! – djangodude Sep 27 '12 at 23:34

0 Answers0