Gần đây tôi đã cập nhật từ Python 2.5 lên 2.7 (tôi đã thử 2.6 trong thời gian phức tạp) và trong khi mọi thứ hoạt động tốt từ dòng lệnh hoặc trong máy chủ Django, mod_wsgi không thể tải bất kỳ mô đun nào chứa DLL (pyd) được tạo bằng MSVC.Tại sao không có DLL Python được xây dựng với tải MSVC với mod_wsgi?
Ví dụ, nếu tôi xây dựng phiên bản riêng của tôi về pycrypto hoặc lxml sau đó tôi sẽ nhận được lỗi sau đây chỉ từ mod_wsgi:
ImportError at/
DLL load failed: The specified module could not be found.
Ngay cả những chương trình PIL chính thức sẽ thất bại trong việc nhập khẩu các mô-đun _imaging C trong mod_wsgi nhưng đó có thể là một vấn đề khác.
Tuy nhiên, nếu tôi sử dụng phiên bản pycrypto được xây dựng với MinGW từ một nơi nào đó như http://www.voidspace.org.uk/python/modules.shtml#pycrypto thì nó sẽ nhập tốt ngay cả trong mod_wsgi. Tôi không tìm thấy giải pháp này thỏa đáng mặc dù vì toàn bộ lý do tôi cập nhật Python là để tránh tìm kiếm các tệp nhị phân dựng sẵn và tôi không thể tự xây dựng chúng vì MinGW không thành công> 50% thời gian cho tôi.
EDIT2: Tôi nhận thấy điều này trong Python27/Lib/distutils/msvc9compiler.py trên dòng 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
này có thể giải thích lý do tại sao mọi thứ hoạt động từ dòng lệnh nhưng không phải trong mod_wsgi. Nhận xét tất cả điều này có vẻ như khắc phục được sự cố nhưng không cảm thấy thích sửa lỗi thích hợp. Các câu hỏi bây giờ là nơi để đặt msvcr90.dll để Apache có thể sử dụng nó? Tôi nhận thấy rằng thư mục bin của Apache chứa msvcr70.dll và msvcr80.dll nhưng đặt 90 trong đó không hoạt động.
Bỏ qua loại bỏ biểu hiện làm việc cho tôi dưới IIS quá với pyodbc – lambacck