- r - 以节省内存的方式增长 data.frame
- ruby-on-rails - ruby/ruby on rails 内存泄漏检测
- android - 无法解析导入android.support.v7.app
- UNIX 域套接字与共享内存(映射文件)
在 osx 加载器上,@loader_path 解析为通用二进制对象的位置,@executable_path 解析为可执行文件的位置。在 Linux 上,显然只有 $ORIGIN,它解析为可执行文件路径。 linux 加载器中是否有一个隐藏的功能来指定通用 ELF 对象的动态搜索路径?或者 $ORIGIN 对 so 对象的行为可能不同?
Linux 也有 $LIB 和 $PLATFORM,但它们没有提供我需要的东西。
最佳答案
$ORIGIN
是被加载对象的位置,所以在可执行文件和可执行文件加载的共享库中是不同的。
编辑:这是我执行的一个小测试:
~$ mkdir /tmp/tests
~$ cd /tmp/tests
tests$ mkdir good bad
tests$ gcc -fPIC -shared -o good/libtest.so -Wl,-rpath,\$ORIGIN -x c - <<< 'int puts(const char*); void foo() { puts("good"); }'
tests$ gcc -fPIC -shared -o bad/libtest.so -Wl,-rpath,\$ORIGIN -x c - <<< 'int puts(const char*); void foo() { puts("bad"); }'
tests$ gcc -fPIC -shared -o good/libtest2.so -Wl,-rpath,\$ORIGIN -x c - -ltest -Lgood <<< 'void foo(); void bar() { foo(); }'
tests$ gcc -o bad/a.out good/libtest2.so -x c - -Wl,-rpath,\$ORIGIN -Wl,-rpath-link,good <<< 'void bar(); int main() { bar(); }'
tests$
tests$ readelf -d bad/* good/* | grep RPATH
0x000000000000000f (RPATH) Library rpath: [$ORIGIN]
0x000000000000000f (RPATH) Library rpath: [$ORIGIN]
0x000000000000000f (RPATH) Library rpath: [$ORIGIN]
0x000000000000000f (RPATH) Library rpath: [$ORIGIN]
tests$
tests$ ldd bad/a.out
linux-vdso.so.1 => (0x00007faf2f295000)
good/libtest2.so (0x00007faf2f092000)
libc.so.6 => /lib64/libc.so.6 (0x0000003949800000)
libtest.so => /tmp/tests/good/libtest.so (0x00007faf2ee66000)
/lib64/ld-linux-x86-64.so.2 (0x0000003949400000)
tests$ bad/a.out
good
我认为这证明它有效,所有内容都有 RPATH=$ORIGIN
,可执行文件明确链接到 libtest2.so
,它获取 libtest.so
在它自己的目录而不是可执行文件的目录中。
使用 LD_DEBUG=libs bad/a.out
显示:
[...]
17779: find library=libtest.so [0]; searching
17779: search path=/tmp/tests/good/tls/x86_64:/tmp/tests/good/tls:/tmp/tests/good/x86_64:/tmp/tests/good (RPATH from file good/libtest2.so)
[...]
即在查找 good/libtest2.so
的 libtest.so
依赖项时,搜索路径使用 good/libtest2.so
的 RPATH,它展开到 /tmp/tests/good
这是 good/libtest2.so
的 $ORIGIN
而不是 $ORIGIN
的可执行文件。
关于linux - linux 上 rpath 规范的 @loader_path 等价物是什么?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/26280738/
macos high sierra 10.13.1 xcode 9.2 matlab 2017b 在 2017b 版本的 mac matlab 中运行程序时,我尝试从这个 link 运行 pmtk3在
在 osx 加载器上,@loader_path 解析为通用二进制对象的位置,@executable_path 解析为可执行文件的位置。在 Linux 上,显然只有 $ORIGIN,它解析为可执行文件路
我正在尝试解决使用 Rust 加载外部库的问题。 输入: 我有一个可执行文件 rtest 和一个 dylib libcpp2rs.dylib。该库通过 FFI 链接到可执行文件: #[link(nam
我有一个名为 Tripla 的应用程序,它可以通过适用于 iOS 8 设备的 Google Drive 同步数据。但是,在 iOS 9 设备上同步数据时会崩溃。因此,我尝试通过最新的库升级 Googl
我是一名优秀的程序员,十分优秀!