New submission from Craig Holmquist <[EMAIL PROTECTED]>:
Applications on Windows that don't link to the MSVCR90.DLL via a
manifest are broken with Python 2.6.1. This includes apps that link
with the C library statically and apps that link with other versions of
it. These applications worked fine with Python 2.6.
To test this, I created a simple application that did nothing but call
Py_Main (compiled with VS2008). When that app links with the C library
statically, attempting to import the socket module gives this error:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\Python26\lib\socket.py", line 46, in <module>
import _socket
ImportError: DLL load failed: The specified module could not be found.
When that app links with the C library dynamically, it works properly.
In particular, this issue breaks mod_python. From the Apache error log:
[Sat Dec 06 00:49:21 2008] [error] make_obcallback: could not import
mod_python.apache.\n
Traceback (most recent call last):
File "C:\Python26\lib\site-packages\mod_python\apache.py", line 29, in
<module>
import cgi
File "C:\Python26\Lib\cgi.py", line 40, in <module>
import urllib
File "C:\Python26\Lib\urllib.py", line 26, in <module>
import socket
File "C:\Python26\lib\socket.py", line 46, in <module>
import _socket
ImportError: DLL load failed: A dynamic link library (DLL)
initialization routine failed.
I'm guessing this is a side-effect of the fix for #4120. Since modules
like _socket.pyd don't have manifests that tell Windows where to find
the side-by-side assembly to load, and the application loading
_socket.pyd doesn't have it in its manifest either, Windows has no clue
where to find MSVCR90.dll.
Something I discovered (by accident) is that, if there's an external
manifest in the same folder as the hosting application (ie,
testpy.exe.manifest) that points to the C runtime, it fixes the problem,
even if the host app links statically to the C runtime. I don't recall
off-hand whether these external manifests take precedence over the
internal ones, but in this case it seems to provide enough information
to Windows that it can resolve the dependency.
----------
components: Windows
messages: 77133
nosy: craigh
severity: normal
status: open
title: 2.6.1 breaks many applications that embed Python on Windows
type: behavior
versions: Python 2.6
_______________________________________
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4566>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
