Library not loaded: @rpath/libffi.6.dylib

[mrclary]

I don't know if this is a bug, but I'm having trouble building an application that will work on other computers.

I've successfully built the app bundle on one computer and the application runs properly. When moving the application to another computer, however, I get the following error upon launch:

Traceback (most recent call last):
  File "/Users/ryan/Desktop/Spyder.app/Contents/Resources/__boot__.py", line 96, in <module>
    _setup_ctypes()
  File "/Users/ryan/Desktop/Spyder.app/Contents/Resources/__boot__.py", line 88, in _setup_ctypes
    from ctypes.macholib import dyld
  File "/Users/ryan/Desktop/Spyder.app/Contents/Resources/lib/python3.8/ctypes/__init__.py", line 7, in <module>
    from _ctypes import Union, Structure, Array
ImportError: dlopen(/Users/ryan/Desktop/Spyder.app/Contents/Resources/lib/python3.8/lib-dynload/_ctypes.so, 2): Library not loaded: @rpath/libffi.6.dylib
  Referenced from: /Users/ryan/Desktop/Spyder.app/Contents/Resources/lib/python3.8/lib-dynload/_ctypes.so
  Reason: image not found
2020-03-26 14:17:12.087 Spyder[11370:2901156] Spyder Error

I'm guessing that I'm not giving py2app the right information to link libffi.6.dylib (and possibly others?), but I'm not sure how to do that. Although, from the traceback, I see that none of the application code has executed yet, just the py2app generated boilerplate stuff in boot.py.

I've looked through py2app examples and done exhaustive google searches to no avail.
Perhaps someone here can help me out or tell me where to start and point me in the right direction?

[ronaldoussoren]

What installation of Python do you use (Python.org installer, homebrew, ...)?

py2app currently doesn't handle @rpath correctly, fixing this will require changes to the way py2app and macholib build standalone bundles.

[mrclary]

I've been building from a virtualenv populated by pip, but originating from anaconda. Here is my sequence...

(conda) >> python -m venv --clear --copies env
(conda) >> source env/bin/activate
(env) (conda) >> pip install -r <list of required packages>

[mrclary]

Okay, so it seems that I've been able to get it to work by creating a virtual environment as before, except originating from homebrew.

(conda) >> conda deactivate
>> /usr/local/opt/[email protected]/bin/python3 -m venv --clear --copies env
>> source env/bin/activate
(env) >> pip install -r <list of required packages>

Why should the creator of the virtual environment make a difference? Isn't that the whole purpose of a virtual environment? to isolate it from any other environment? Is there something I'm missing here or some way to establish the virtual environment properly from conda?

[mrclary]

as an additional note, if using pyenv to create a virtual environment, it is required to set the environment variable PYTHON_CONFIGURE_OPTS="--enable-framework".

>> PYTHON_CONFIGURE_OPTS="--enable-framework"
>> pyenv install 3.8.2
>> pyenv virtualenv 3.8.2 env

[petioptrv]

@mrclary, you just became my new favorite plasma physicist

[mrclary]

@mrclary, you just became my new favorite plasma physicist

Thankyou, what did I do to deserve such honor? Am I the only plasma physicist on your list? In that case I'm also your least favorite plasma physicist :-)

[petioptrv]

@mrclary, you just became my new favorite plasma physicist

Thankyou, what did I do to deserve such honor? Am I the only plasma physicist on your list? In that case I'm also your least favorite plasma physicist :-)

Why would you ever assume you're the only plasma physicist on my list?! You solved my issue, hence you're the plasma physicist MVP. Out of curiosity, why does a plasma physicist need a GUI (assuming packaging goes hand-in-hand with GUIs)?

[mrclary]

I use Spyder for my IDE, as do several of my fellow physicists at TAE Technologies. Currently it is launched from command line but it is desirable to have Spyder built as a standalone Mac application.

[ronaldoussoren]

Virtual environments isolate different projects from each other, but don't isolate you from issues with the base interpreter. In this case there is nothing wrong with the way anaconda installs Python, but it uses a platform feature that py2app does not support.

The TL/DR is to use a Python installation that doesn't use the @rpath feature when you want to use py2app.

Let my try to explain the issue without getting too technical:

• py2app creates the app bundle by copying your application code and (recursively) all dependencies on Python modules (including extensions)
• py2app then uses macholib to copy shared library dependencies into your application bundle (excluding system libraries)

This ensures that the generated application bundle is standalone and can be used on other machines.

When py2app and macholib were created a shared library contained a list of absolute path names of their dependencies. Between that time and now Apple added some magic variables that could be used instead of absolute path names, in particular:

• @executable_path/NAME: NAME is a path relative to the location of the main executable of the app bundle
• @loader_path/NAME: NAME is a path relative to the current executable or shared library
• @rpath/NAME: NAME is a path relative to the "rpath", which is specified in the binary header

Py2app/macholib contains basic support for the first two, but not for the latter because that requires significant changes to the way py2app and macholib integrate.

I definitely want to support the @rpath features, but that requires a lot more work than I can manage at the moment.