[New-bugs-announce] [issue4566] 2.6.1 breaks many applications that embed Python on Windows

[Craig Holmquist]

New submission from Craig Holmquist <craigholm at gmail.com>:

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 <report at bugs.python.org>
<http://bugs.python.org/issue4566>
_______________________________________