views:

343

answers:

2

Hi there,

I'm including python.h in my VC++ dll project which causes an implicit linking with python25.dll. However I want to load a specific python25.dll (several can be present on the computer) so I created a very simple manifest file named test.manifest:

<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
    <file name="python25.dll" />
</assembly>

and I'm merging it with the automatically embedded manifest file generated by Visual Studio thanks to:

Configuration Properties -> Manifest Tool -> Input and Output -> Additional Manifest Files
-->$(ProjectDir)\src\test.manifest

What happens is that python25.dll is now loaded twice: the one requested by the manifest, and the one that Windows should find through its search order.

process explorer

Why is that happening and how can I just load the dll pointed by the manifest?

Thanks -David

+1  A: 

Dependency Walker is usually the best tool for resolving this kind of problem. I'm not too sure how well it handles manifests though...

Where in this entangled mess in the actual process executable file? Two possibilites come to mind:

  1. You are writing a python extension? dll. So the python process is loading your dll and it would already have its own python25.dll dependency.

  2. The exe loading your dll is being built with header files and libs provided by the dll project. So it is inheriting the #pragma comment(lib,"python25.lib") from your header file and as a result is loading the dll itself.

My problem with the 2nd scenario is, I'd expect the exe, and your dll, to be in the same folder in the case that the exe is implicitly loading your dll. In which case the exe, your dll and they python25.dll are all already in the same folder. Why then would the system32 version ever be loaded? The search order for implicitly loaded dlls is always in the application exe's folder.

So the actual interesting question implicit in your query is how is the system32 python26.dll being loaded at all?

Chris Becke
Thanks Chris, I clarified the scenario in an answer I posted. Now I figured out that the issue is caused by the boost.python dll...
David
Somehow your dll's activation context is not being used by the boost - are you doing a static, or dynamic load, of boost?, and of python dll?Does the boost dll have its own manifest that could reset the AC and/or somehow explicitly reference the python dll in system32?
Chris Becke
+1  A: 

I made some progress for the understanding of the issue.

First let me clarify the scenario:

  • I'm building a dll that both embeds and extends Python, using python C API and Boost.Python
  • thus I'm providing a python25.dll in the same folder as my dll, as well as a boost_python-vc90-mt-1_39.dll
  • then I have an exe which is a demo to show how to link to my dll: this exe doesn't have to be in the same folder as my dll, as long as the dll can be found in the PATH (I'm assuming that the end user may or may not put it in the same folder)

Then, when running the exe, the current directory is not the one containing python25.dll, and that's why the search order is used and some other python25.dll can be found before mine.

Now I figured out that the manifest technique was the good approach: I managed to redirect the loading to "my" python25.dll.

The problem is that this is the boost dll boost_python-vc90-mt-1_39.dll that's responsible for the "double" loading!

If I don't load this one, then python25.dll is correctly redirected. Now I somehow have to figure out how to tell the boost dll not to load another python25.dll...

David
I managed to recompile boost.python libs with "embed-manifest=off" option.Miracle! "python25.dll" no more loaded twice.But now, whenever I import a pyd extension from my C++ code, it's loaded twice again... endless issue...
David