In general, if the dependent DLL is in the same directory as the module loading it (the .pyd or .exe), then it should be loaded first. If it's alongside the .exe, it should be loaded before any of the other search paths. If it's being loaded directly from Python, your best option is to resolve the full path before trying to load it (via ctypes or whatever).
I have argued in the past about trying to hack the importer in order to "fix" this (since any fix is highly likely to break currently working install layouts), and this sounds like it is best solved by putting dependencies in an expected location.
However, I don't know how much impact the msys2 aspect of this has. You mention "lib\pythonxx\lib-dynload", which is not present in a normal Python install on Windows. So possibly you're already on a non-standard build, which means my advice is pretty useless to you.
There are also significant parts of both zlib and openssl available in a normal Python install on Windows, so perhaps you don't need to include alternate copies of those with your package? Are there particular features or APIs missing that you need?
On 23Jul2018 1531, Eric Le Lay wrote:
I encountered a problem with the Windows packaging of gPodder using msys2:
basic libraries (zlib, openssl) depended upon by python platform-specific modules are loaded preferably :
- from lib-dynload (where they are not)
- from the Windows directory (can be any version)
- from the binary directory, next to gpodder.exe (where they are)
So an old zlib1.dll installed by another application in c:\Windows was loaded, incompatible with libpng and gPodder couldn't start.
I don't know what's the best approach to solve it:
- copy those libraries to lib\pythonxx\lib-dynload (works)
- preload them in my main script before they are loaded by the module (works)
- patch something in python (dynload_win.c ?) to search first in the executable directory (not tried)
Please can you provide me with insight on this?
Details in the issue: