[Python-Dev] [Windows] how to prevent the wrong version of zlib1.dll to be used by lib-dynload modules

Steve Dower steve.dower at python.org
Mon Jul 23 12:30:39 EDT 2018


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?

Cheers,
Steve

On 23Jul2018 1531, Eric Le Lay wrote:
> Hello list,
> 
> I encountered a problem with the Windows packaging of gPodder[1]
> using msys2:
> 
> basic libraries (zlib, openssl) depended upon by python
> platform-specific modules are loaded preferably :
>   1. from lib-dynload (where they are not)
>   2. from the Windows directory (can be any version)
>   3. 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: [1]
> 
> Thanks,
> 
> [1] https://github.com/gpodder/gpodder/issues/478


More information about the Python-Dev mailing list