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)
…
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)
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?
Cheers,
Tim
