Le Mon, 23 Jul 2018 10:47:33 -0700, Nathaniel Smith <n...@pobox.com> a écrit :
> On Mon, Jul 23, 2018, 08:22 Eric Le Lay <cont...@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
pgpit6WMhu9Ni.pgp
Description: Signature digitale OpenPGP
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
