osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[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[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)
> >  
> 
> 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:
> https://github.com/njsmith/machomachomangler/blob/master/README.rst#pe-features
> 
> 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.)
> 
> -n
> 
> >  

Thanks Steve, Nathaniel, eryk for your detailed answers.

I use the mingw64-python3 package in msys2:
https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-python3
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)
   https://github.com/quodlibet/quodlibet/issues/2817

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
machomachomangler.

--
Eric
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: Signature digitale OpenPGP
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180724/37f95ebe/attachment.sig>