Why aren't there any Python DLLs built with MSVC loading using mod_wsgi?

Question

I recently upgraded from Python 2.5 to 2.7 (I tried 2.6 during my problems), and although everything works fine from the command line or on the Django server, mod_wsgi cannot load any module containing a DLL (pyd) built with using MSVC.

For example, if I create my own versions of pycrypto or lxml, then I will get the following error only from mod_wsgi:

ImportError at / DLL load failed: The specified module could not be found. 

Even the official PIL binaries will not be able to import the _imaging C module into mod_wsgi, but this may be another problem.

However, if I use the version of pycrypto built with MinGW, from somewhere like http://www.voidspace.org.uk/python/modules.shtml#pycrypto , it will even import into mod_wsgi. I did not find this solution satisfactory, although since the whole reason I updated Python was to avoid having to look for ready-made binaries, and I cannot create them myself, because MinGW is not working> 50% of the time for me .

EDIT2: I noticed this in Python27 / Lib / distutils / msvc9compiler.py on lines 680-705:

 try: # Remove references to the Visual C runtime, so they will # fall through to the Visual C dependency of Python.exe. # This way, when installed for a restricted user (eg # runtimes are not in WinSxS folder, but in Python own # folder), the runtimes do not need to be in every folder # with .pyd's. manifest_f = open(manifest_file) try: manifest_buf = manifest_f.read() finally: manifest_f.close() pattern = re.compile( r"""<assemblyIdentity.*?name=("|')Microsoft\."""\ r"""VC\d{2}\.CRT("|').*?(/>|</assemblyIdentity>)""", re.DOTALL) manifest_buf = re.sub(pattern, "", manifest_buf) pattern = "<dependentAssembly>\s*</dependentAssembly>" manifest_buf = re.sub(pattern, "", manifest_buf) manifest_f = open(manifest_file, 'w') try: manifest_f.write(manifest_buf) finally: manifest_f.close() except IOError: pass 

This probably explains why everything works from the command line, but not in mod_wsgi. Commenting all of this seems to fix the problem, but doesn't seem like the correct fix. Now the question is, where to put msvcr90.dll so that Apache can use it? I noticed that the Apache bin folder contains the msvcr70.dll and msvcr80.dll files, but the attachment 90 in it does not work.

Answer 1

I had a similar problem and ended up finding a solution here : download / upgrade your Apache server with one of http://www.apachelounge.com/download/ .

Answer 2

While I don't know anything about mod_wsgi, I dare to suggest that the most likely reason is the lack of dependencies at runtime. You can test your MSVC build using Dependency Walker, which comes with MSVC (for example, in MSVC 2005, it is located in \ Common7 \ Tools \ Bin \ Depends.Exe). It will show you which DLLs are needed for the binary.

As another workaround, it should be possible to create your modules with a statically linked runtime (see "Project Properties" → "C / C ++" → "Code Generation" → "Runtime" - select "Multithreading" (and not " Multithreaded DLL "); if you are building from the command line, make sure that /MT used instead of /MD ). However, problems may arise if runtime-dependent objects (such as FILE * objects) cross the module boundary.

UPD If you have the correct VC set installed, the cause may be a problem with the SxS configuration (i.e. the manifest itself .pyd itself is erroneous or missing or conflicts with the manifest of the application that loads .pyd). You can use the sxstrace utility to find out what exactly is happening. See Diagnosing SideBySide Failures .

Have you also tried static linking of the runtime? Or, better yet, check what host process requirements are.

Answer 3

I was getting this error with zmq. The solution was to include the python27.dll manifest in the libzmq.pyd file (and it most likely will work for other pyd / dlls). Make sure you are using all 64-bit or all 32-bit versions.

 "C:\Program Files (x86)\Windows Kits\8.0\bin\x64\mt.exe" -inputresource:C:\windows\system32\python27.dll;#2 -outputresource:libzmq.pyd;#2 

See https://code.google.com/p/pyodbc/issues/detail?id=214