This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author craigh
Recipients craigh
Date 2008-12-06.15:28:51
SpamBayes Score 2.9205416e-11
Marked as misclassified No
Message-id <1228577334.37.0.676469955994.issue4566@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2008-12-06 15:28:59craighsetrecipients: + craigh
2008-12-06 15:28:54craighsetmessageid: <1228577334.37.0.676469955994.issue4566@psf.upfronthosting.co.za>
2008-12-06 15:28:53craighlinkissue4566 messages
2008-12-06 15:28:51craighcreate