gpt4 book ai didi

linker - 为什么链接器会更改共享库名称?

转载 作者:行者123 更新时间:2023-12-04 16:30:37 27 4
gpt4 key购买 nike

使用通过“node-gyp”传递的链接器命令行选项,我指定了我希望程序链接的库路径和库名称。但是生成的可执行文件没有引用我指定的文件,它在 /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似乎正确传递了选项,因为链接器返回 /usr/bin/ld: cannot find -la-oboe如果我改变 -L不包含 libao-oboe.so 的路径.如果我将请求的库的名称更改为不同于 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 .so 文件中的 SONAME 字段是“基本兼容版本”。从我在上述问题中发现的行为可以清楚地看出,ld 将 SONAME 插入到链接到共享库的文件中——而不是 ld 命令中指定的文件名。

重命名 .so 文件不会更改 SONAME,因此链接到重命名文件的可执行文件将尝试加载由 SONAME 字段命名的库,而不是文件名。

我的解决方案是不重命名文件。

关于linker - 为什么链接器会更改共享库名称?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/46115072/

27 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com