2010-09-14 5 views
6

Ich habe vor kurzem von Python 2.5 auf 2.7 aktualisiert (ich habe 2.6 während meiner Probleme versucht) und während alles von der Kommandozeile oder im Django runserver funktioniert, kann mod_wsgi kein Modul laden, das mit MSVC erstellte DLLs (pyd) enthält.Warum werden keine mit MSVC erstellten Python-DLLs mit mod_wsgi geladen?

Zum Beispiel, wenn ich meine eigenen Versionen von PyCrypto oder lxml bauen dann werde ich die folgende Fehlermeldung erhalten nur von mod_wsgi:

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

Selbst die offiziellen PIL-Binärdateien wird scheitern die _imaging C-Modul in mod_wsgi importieren aber das könnte ein anderes Problem sein.

Allerdings, wenn ich eine Version von pycrypto mit MinGW gebaut von irgendwo wie http://www.voidspace.org.uk/python/modules.shtml#pycrypto dann wird es auch in mod_wsgi fein importieren. Ich finde diese Lösung nicht zufriedenstellend, da ich Python komplett aktualisiert habe, um zu vermeiden, dass ich nach vorgefertigten Binärdateien suchen muss, und ich kann sie nicht selbst erstellen, weil MinGW> 50% der Zeit für mich ausfällt.

EDIT2: Ich bemerkte dies in Python27/Lib/distutils/msvc9compiler.py auf den Leitungen 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 

Das erklärt vermutlich, warum alles von der Kommandozeile aber nicht in mod_wsgi funktioniert. All dies zu kommen scheint das Problem zu beheben, fühlt sich aber nicht wie die richtige Lösung an. Die Frage ist jetzt, wo man msvcr90.dll setzen muss, damit Apache es benutzen kann? Ich stelle fest, dass Apache's bin-Ordner msvcr70.dll und msvcr80.dll enthält, aber das Hineingeben von 90 funktioniert nicht.

+1

manifest Skipping entfernen für mich unter IIS auch mit Pyodbc – lambacck

Antwort

1

Während ich nichts über mod_wsgi weiß, wage ich zu vermuten, dass der wahrscheinlichste Grund fehlende Laufzeitabhängigkeiten ist. Möglicherweise möchten Sie Ihre MSVC-Build mit Dependency Walker untersuchen, die mit MSVC ausgeliefert wird (z. B. in MSVC 2005 befindet es sich unter \ Common7 \ Tools \ Bin \ Depends.Exe). Es zeigt Ihnen, welche DLLs von einer Binärdatei benötigt werden.

Als weitere Ausweichlösung sollte es möglich sein, Ihre Module mit statisch verknüpfter Runtime zu erstellen (siehe Projekteigenschaften -> C/C++ -> Codegenerierung -> Runtime - wählen Sie "Multithread" (nicht "Multithread DLL"); oder, wenn Sie von der Befehlszeile aus erstellen, stellen Sie sicher, dass /MT anstelle von verwendet wird. Es kann jedoch Probleme geben, wenn von der Laufzeit abhängige Dinge (z. B. FILE * -Objekte) die Modulgrenze überschreiten.

UPD Wenn Sie richtig VC redist installiert haben, kann der Grund ein Problem mit SxS-Konfiguration (dh Manifest der .pyd selbst falsch ist oder fehlt, oder Konflikte mit manifester der Anwendung, die die .pyd lädt). Sie können das Dienstprogramm sxstrace verwenden, um zu sehen, was genau vor sich geht. Siehe Diagnosing SideBySide failures.

Haben Sie auch versucht, die Laufzeit statisch zu verknüpfen? Oder, noch besser, prüfen Sie, welche Anforderungen Ihr Host-Prozess erfüllt.

+0

arbeitete sie fehlen msvcr90.dll (und GPSVC und IESHIMS). Ich legte MSVCR90.DLL neben AES.pyd und Dependency Walker-Pässe, aber Apache gibt einen Laufzeitfehler. Ich habe die VC redist und MSVCR90.dll ist in verschiedenen Ordnern unter C: \ Windows \ winsxs. Irgendwelche Ideen? –

+0

Ich habe die ursprüngliche Frage bearbeitet, um zu zeigen, wie AES.pyd tatsächlich aufgebaut ist. Es wäre als Kommentar verstümmelt worden. –

+0

@Kyle MacFarlane - Ich habe meine Antwort in Reaktion auf die Kommentare – atzz

0

Ich bekam diesen Fehler mit zmq. Die Lösung bestand darin, das Manifest python27.dll in die Datei libzmq.pyd aufzunehmen (und es wird höchstwahrscheinlich für andere pyd/dlls funktionieren). Stellen Sie sicher, dass Sie alle 64-Bit oder alle 32-Bit verwenden.

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

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