On 19.06.2013 12:51, M.-A. Lemburg wrote:
On 19.06.2013 10:01, Malte Forkel wrote:
Am 19.06.2013 00:19, schrieb M.-A. Lemburg:
Are you using our prebuilt or egg distribution of eGenix mx Base, or compiling it from source ?
I'm using the prebuilt distribution (egenix-mx-base-3.2.6.win-amd64-py2.7.msi).
Thanks to the kind advice of Steve Dower, I have since updated OpenVPN, the application had installed the 32-bit version of MSVCR90.DLL in its own directory, to a newer 64-bit version which does not install local CRTs.
According to Dependency Walker, it had been OpenVPN's copy of MSVCR90.DLL that mxDateTime.pyd referenced, probably due to the OpenVPN's entry in the user's search path.
Interesting. I just tried that on my system and indeed, see the reference to OpenVPN as well. The same happens with all other .pyd files in the Python installation.
Now, according to Dependency Walker, mxDateTime.pyd refeference to MSVCR90.DLL remains unresolved. But there are no problems when I run the install script or import mx.DateTime myself.
We'll investigate that some more. It may have something to do with the way distutils handles manifests for Python extensions at compile/link time. The extensions should get all the MSVCR90.DLL symbols from the DLL loaded into the PYTHON27.DLL process.
The unresolved reference to MSVCR90.DLL is shown for all distutils compiled extensions, so this is most likely the result of distutils removing the manifest from compiled C extensions to force the linker to use the Python DLL's CRT libs - this in return avoids problem with having to place the CRT manifests into each extension directory. I have no idea why the Windows linker attempts to load a x86 DLL into a x64 process. The manifest included with OpenVPN clearly shows that the DLL is for a different platform, even though it uses the same version as the one listed in the python.exe manifest. -- Marc-Andre Lemburg Director Python Software Foundation http://www.python.org/psf/