Unsafe use of relative rpath with restricted binary?

Environments macOS
1

Hi,

Recently our macOS builds have started to fail with the following error:

Running appleseed.python unit tests...
Traceback (most recent call last):
  File "sandbox/lib/Debug/python/appleseed/test/runtests.py", line 31, in <module>
    from testbasis import *
  File "/Users/travis/build/appleseedhq/appleseed/sandbox/lib/Debug/python/appleseed/test/testbasis.py", line 30, in <module>
    import appleseed as asr
  File "/Users/travis/build/appleseedhq/appleseed/sandbox/lib/Debug/python/appleseed/__init__.py", line 41, in <module>
    from _appleseedpython import *
ImportError: dlopen(/Users/travis/build/appleseedhq/appleseed/sandbox/lib/Debug/python/appleseed/_appleseedpython.so, 2): Library not loaded: libSeExpr.dylib
  Referenced from: /Users/travis/build/appleseedhq/appleseed/sandbox/lib/Debug/python/appleseed/_appleseedpython.so
  Reason: unsafe use of relative rpath libSeExpr.dylib in /Users/travis/build/appleseedhq/appleseed/sandbox/lib/Debug/python/appleseed/_appleseedpython.so with restricted binary

This used to work fine until less than a month ago.

Here is a full build log:
https://travis-ci.org/appleseedhq/appleseed/jobs/652228438

Here is our build script:

I have found this topic on Stack Overflow:

It seems that we could fix (or rather, work around) the problem by using install_name_tool to change libSeExpr.dylib to /Users/travis/build/appleseedhq/appleseed/lib/libSeExpr.dylib in _appleseedpython.so, but why would we suddenly need to do that? What changed?

2

My first guess would be Homebrew.

1 Like
3

All I could find about this problem is this: ios - dylib Library not loaded due to restricted binary after apple code signing - Stack Overflow

Beginning with macOS 10.10.4, Gatekeeper verifies that no libraries are loaded from outside an app bundle . If an app uses @rpath or an absolute path to link to a dynamic library outside of the app, Gatekeeper rejects the app . This restriction applies to the app’s main executable and any other executable in the bundle, including libraries. This restriction applies even if the path does not exist (which normally causes the dynamic linker to fall back to a library inside the bundle). The error will appear in the system log, with a message like the following for an app MyApp.app trying to link against the library libLibrary.dylib in the nonstandard location /foo

It makes sense, but this appears to be a relatively old behavior and I’m not sure how an Homebrew update could have an effect on this.