> On 13 Dec 2020, at 04:53, Timothy M. Shead <t...@shead-custom-design.com>
> wrote:
>
> Many thanks for py2app, of all the packaging apps I’ve tried, it’s been the
> most usable by far; that said, I have questions. Using conda, python 3.8.5,
> and py2app 0.22 on MacOS 10.15.7 with the following test app:
>
> # hello.py
> print(“Hello, World!”)
>
> And the following default setup.py:
>
> from setuptools import setup
>
> APP = ["hello.py”]
> DATA_FILES = []
> OPTIONS = {}
>
> setup(
> app=APP,
> data_files=DATA_FILES,
> options={"py2app": OPTIONS},
> setup_requires=["py2app”],
> )
>
> Everything builds and runs fine:
>
> $ python setup.py py2app
> $ dist/hello.app/Contents/MacOS/hello
> Hello, World!
>
> However, upon closer inspection, I see that there are a couple of libs that
> are being loaded from outside the bundle:
>
> $ DYLD_PRINT_LIBRARIES=1 dist/hello.app/Contents/MacOS/hello
> ...
> /Users/tshead/miniconda3/envs/flow/lib/libz.1.dylib
> /Users/tshead/miniconda3/envs/flow/lib/libffi.7.dylib
>
> Focusing on libz, I see that it’s being loaded from a library that is part of
> the bundle:
>
> $ otool -L
> dist/hello.app/Contents/Resources/lib/python3.8/lib-dynload/zlib.so
> dist/hello.app/Contents/Resources/lib/python3.8/lib-dynload/zlib.so:
> @rpath/libz.1.dylib (compatibility version 1.0.0, current version
> 1.2.11)
> …
How was Python build?
>
> And when I look at the main executable, the second rpath looks questionable:
>
> $ otool -l dist/hello.app/Contents/MacOS/hello
> …
> Load command 16
> cmd LC_RPATH
> cmdsize 32
> path @loader_path/../lib (offset 12)
> Load command 17
> cmd LC_RPATH
> cmdsize 48
> path @loader_path/../../../../../ (offset 12)
Was this file created by py2app, or did you change it afterwards? The stub
executable in current releases of py2app should not contain LC_RPATH entries at
all.
>
> What is the right approach to address this? Manually copy the missing .dylib
> files into dist/hello.app/Contents/lib? I’m too new to know what to expect
> from py2app, but I’m surprised that it would be necessary for something as
> ubiquitous as zlib?
Py2app, or rather the macholib library used by py2app, does not process @rpath
correctly. The code is older than the introduction of this feature and is not
easily adjusted for it because some information needed for correctly dealing
with @rpath and @loader_path is lost before the code that should use the
information is active. I have rewriting that code on my too long todo list.
Note that this works for me, with the Python.org <http://python.org/>
installation of Python.
Ronald
—
Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/
>
> Cheers,
> Tim
>
> _______________________________________________
> Pythonmac-SIG maillist - Pythonmac-SIG@python.org
> https://mail.python.org/mailman/listinfo/pythonmac-sig
> unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
_______________________________________________
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
https://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: https://mail.python.org/mailman/options/Pythonmac-SIG
