在osx加载器上,@ mount_path解析为通用二进制对象的位置,@ executable_path解析为可执行文件的位置。在Linux上,显然只有$ ORIGIN,它解析为可执行路径。 linux加载器中是否有隐藏的功能来为通用ELF对象指定动态搜索路径?或者,对于这样的对象,$ ORIGIN的行为可能不同?
Linux也有$ LIB和$ PLATFORM,但它们没有提供我需要的东西。
答案 0 :(得分:5)
$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)
[...]
即。在查找libtest.so
的{{1}}依赖关系时,搜索路径使用来自good/libtest2.so
的RPATH,其扩展为good/libtest2.so
,/tmp/tests/good
来自$ORIGIN
}不是可执行文件的good/libtest2.so
。
答案 1 :(得分:-1)
linux加载程序按以下顺序搜索:
DT_RPATH(在gcc命令行中指定,忽略si DT_RUNPATH存在)
LD_LIBRARY_PATH(在环境中指定)
DT_RUNPATH(在gcc命令行中指定)
ld.so.conf(对于在行上指定的目录并使用ldconfig编译)
/ lib和/ usr / lib