> > 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. > > [snip] > > When Dependency Walker showed a reference from mxDateTime.pyd to > the > 32-bit version of MSVCR90.DLL, it always also showed a reference from > PYTHON27.DLL to the 64-bit version of MSVCR90.DLL.
My suspicion is that this is due to OpenVPN adding itself to the PATH variable. The default Python install will put PYTHON27.DLL into System32 (for a 64-bit install), and so it will try and resolve dependencies in the same directory first. This is probably why it finds the correct MSVCR90.DLL (it may also be that the manifest is correct). Since mxDateTime.pyd is not in System32, it will go through the usual resolution process. System32 is supposed to be checked first, so I'm not sure why the correct version is being bypassed, but that may be because of the lack of manifest. I'd guess that it works for most people because by the time Windows reaches the end of its search, the correct DLL is the only/best/most recent option found. That OpenVPN version provides an alternative, and Windows is choosing it and then failing to load because of the platform mismatch. There's not much I can offer by way of solution. Adding a manifest to the pyd 'should' be the 'correct' solution, but I can't guarantee that it won't cause conflicts elsewhere. Adding a copy of MSVCR90.DLL to the pyd directory would also work, but this is probably riskier when it comes to version mismatches. As I understand, OpenVPN has corrected their side of things already, so this may just be an issue to be aware of for when people hit it in the future. Cheers, Steve _______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
