Я недавно обновился с Python 2.5 до 2.7 (я пробовал 2.6 во время моих хлопот), и хотя все работает нормально из командной строки или с сервера запуска Django, mod_wsgi не может загрузить любой модуль, который содержит DLL (pyd), созданные с помощью MSVC.
Например, если я соберу свои собственные версии pycrypto или lxml, я получу следующую ошибку только от mod_wsgi:
ImportError at /
DLL load failed: The specified module could not be found.
Даже официальные двоичные файлы PIL не смогут импортировать _imaging Cмодуль в mod_wsgi, но это может быть еще одной проблемой.
Однако, если я использую версию pycrypto, созданную с использованием MinGW, где-то вроде http://www.voidspace.org.uk/python/modules.shtml#pycrypto, то он прекрасно импортируется даже в mod_wsgi.Однако я не нахожу это решение удовлетворительным, поскольку единственная причина, по которой я обновил Python, заключалась в том, чтобы избежать необходимости искать предварительно собранные двоичные файлы, и я не могу собрать их самостоятельно, потому что MinGW дает сбой> 50% времени для меня.
EDIT2: я заметил это в Python27 / Lib / distutils / msvc9compiler.py в строках 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 (e.g.
# runtimes are not in WinSxS folder, but in Python's 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
Это, вероятно, объясняет, почему все работает из командной строки, а не в mod_wsgi.Комментирование всего этого, похоже, решает проблему, но не похоже на правильное решение.Вопрос сейчас в том, куда положить msvcr90.dll, чтобы Apache мог его использовать?Я заметил, что папка bin Apache содержит msvcr70.dll и msvcr80.dll, но ввод 90 там не работает.