[Python-Dev] [Windows] how to prevent the wrong version of zlib1.dll to be used by lib-dynload modules
Le Mon, 23 Jul 2018 10:47:33 -0700,
Nathaniel Smith <njs at pobox.com> a ?crit :
> On Mon, Jul 23, 2018, 08:22 Eric Le Lay <contact at elelay.fr> wrote:
> > Hello list,
> > 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 :
> > 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)
> The way we avoid these kinds of issues on Linux is to rename included
> libraries to unique names (e.g. zlib1-aef3742bc3e.dll), and patch the
> extension modules to look for the new names. There's a script
> (auditwheel) that does the heavy lifting. On MacOS there's a similar
> script people use, called "delocate".
> Unfortunately no one has written a script like this for Windows yet. I
> think it'd be neat if eventually we could consolidate all this into
> auditwheel, but there aren't that many people interested in working
> on it. If you wanted to help, the hardest part is already done:
> Alternatively if you just want a hack that works quick, I'd do the
> preload thing. In general you need to do this anyway, if you don't
> have all your extension modules in the same directory. (Unfortunately
> Windows doesn't have the equivalent of RPATH.)
Thanks Steve, Nathaniel, eryk for your detailed answers.
I use the mingw64-python3 package in msys2:
It's not the same as msys2 python3 or Python for Windows. It has
quite a few patches.
While looking into it, I found a similar issue
- on the package https://github.com/Alexpux/MINGW-packages/issues/3381
- on quodlibet (the program I adapted windows packaging from)
For the moment I cowardly favor the quick hack of preloading over
patching dlls or using application-configuration-files.
Regarding auditwheel, isn't it only handling wheel files (*.whl), not
basic dll modules like binascii-cpython-36m.dll? Thanks for the link to
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 833 bytes
Desc: Signature digitale OpenPGP