为什么链接器更改共享库名称? [英] why does the linker change shared library name?
本文介绍了为什么链接器更改共享库名称?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!
问题描述
/usr/lib
中引用了不同的名称。
我正在使用binding.gyp
中的库节引用本地lib
目录。
'libraries': [
'-lao-oboe',
'-L<(module_root_dir)/lib/',
'-Wl,-rpath-link,<(module_root_dir)/lib/',
'-Wl,-rpath,<(module_root_dir)/lib/'
],
node-gyp
似乎正确地传递了选项,因为如果我将-L
路径更改为不包含libao-oboe.so
的路径,链接器将返回/usr/bin/ld: cannot find -la-oboe
。如果我将请求的库的名称更改为与lib
中的名称不同,链接器也会返回错误。
问题是本地库不会在运行时加载。ldd
显示node-gyp
输出文件没有引用指定的文件-它引用的是具有完全不同名称的库-/usr/lib/liboboe-1.0.so.1
。参见ldd
输出的第二行:
linux-vdso.so.1 => (0x00007ffee20f5000)
liboboe-1.0.so.1 => /usr/lib/liboboe-1.0.so.1 (0x00007fa476377000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fa475ff5000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa475c2b000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fa475a27000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fa47580a000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fa475501000)
/lib64/ld-linux-x86-64.so.2 (0x00007fa476922000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fa4752eb000)
本地库目录包含:
lrwxrwxrwx 1 bruce bruce 15 Sep 8 02:50 libao-oboe.so -> libao-oboe.so.1`
-rw-r--r-- 2 bruce bruce 1640848 Aug 31 15:01 libao-oboe.so.1
本地库文件libao-oboe.so.1
与可执行文件中引用的系统库文件相同(如ldd
所示):/usr/lib/liboboe-1.0.so.1
。
链接器是否以某种方式注意到本地文件相同(通过哈希或某个签名)并从标准位置替换库文件?
为什么node-gyp
的输出文件引用的库文件从未在生成过程中被请求?
推荐答案
根据wikipedia - soname文件中的SONAME字段是"基本兼容版本"。从我在上面的问题中发现的行为可以清楚地看出,ld
将SONAME插入到链接到共享库的文件中--而不是ld
命令中指定的文件名。
重命名.so
文件不会更改SONAME,因此链接到重命名文件的可执行文件将尝试加载由SONAME字段而不是文件名命名的库。
我的解决方案是不重命名该文件。
这篇关于为什么链接器更改共享库名称?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!
查看全文