这是一个创建于 1772 天前的主题,其中的信息可能已经有所发展或是发生改变。
app 里面的一个可执行文件 XXX 注册成服务,然后通过 app 来调用它使用,
该可执行文件 XXX 对应的 plist 文件里面指定了 DYLD_LIBRARY_PATH 来获取动态 lib 的绝对路径~/Library/*** ,
现在的问题是:
直接 build 编译出来的 app 文件,调用这个可执行文件 XXX 启动是没问题的,
但是给 app 签名后(该可执行文件 XXX 和对应的依赖库也被签名),
启动这个服务时候动态库是从默认的相对路径 @@HOMEBREW_PREFIX@@/opt/libev/lib/libev.4.dylib 中来获取的,
因为 Apple 对这种相对路径做了权限限制,导致该可执行文件启动失败
具体错误如下
dyld: Library not loaded: @@HOMEBREW_PREFIX@@/opt/libev/lib/libev.4.dylib
Referenced from: /Users/buffer/Library/Application Support/XXX
Reason: unsafe use of relative rpath @@HOMEBREW_PREFIX@@/opt/libev/lib/libev.4.dylib in /Users/buffer/Library/Application Support/XXX with restricted binary
看了下老外对 DYLD_LIBRARY_PATH 有这段描述如下
If you run otool -L MyApp.app/Contents/MacOS/MyApp you'll see the paths to the libraries that MyApp wants to load. If any library isn't found at the specified path then dyld will look for the library in the locations specified by DYLD_FALLBACK_LIBRARY_PATH. Setting DYLD_LIBRARY_PATH causes dyld to look for the library in the given locations ahead of the path that the otool command above returned.
那么按照道理来说,动态库的查找顺序优先级应该是
DYLD_LIBRARY_PATH > 该动态库默认的路径(通过 otool -L MyApp.app 查看) > DYLD_FALLBACK_LIBRARY_PATH
所以,想问下这种获取动态库路径失败,是 Apple 签名造成的嘛?
3 条回复 • 2019-08-28 00:40:56 +08:00
|
|
1
txx 2019-08-27 01:20:28 +08:00 via Android
与其在这里问 不如直接读一下 dyld 源码 几年前读过 还是挺清晰的
|