David Genest wrote:
Subject: Re: [Distutils] Wheels and dependent third party dlls on windows
This is not true. Python loads DLLs with LOAD_WITH_ALTERED_SEARCH_PATH, to allow them to be located alongside the pyd
file. You should therefore be able to ship the dependent dll in the package directory (which wheels support fine).
Ok, so what if the dll is shared in a given environment (multiple extensions use it)?, the shared dll should be copied to every package? Won't that cause multiple loads by the system?
A DLL can only be loaded once per process (python.exe, in this case) and it will be loaded based on its file name (not the full path). Whoever loads first will win every future load for the same filename.
If you're loading it directly, it's fairly easy to rename a DLL to something likely to be unique to your project (or at least to put a version number in it) so that other packages won't use it. There are more complicated approaches using manifests and activation contexts (this is how different .pyd files with the same name can be correctly loaded), but ensuring a unique name is much easier.
If the DLL is loaded implicitly by a .pyd, then as Paul says it should be loaded correctly if it is alongside the .pyd.
Dependency Walker from www.dependencywalker.com is a great tool for checking what DLLs will be loaded by an executable or DLL. I recommend enabling profiling of your python.exe process when you try and import your packages to see where it is looking for its dependencies.
Hope that helps, Steve
Thanks for your response,