Question

使用通过＆＃39; node-gyp＆＃39;传递的链接器命令行选项我指定了我希望程序链接的库路径和库名。但是生成的可执行文件不引用我指定的文件，它在/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的输出文件引用了从未在构建过程中请求的库文件？

Answer 1

根据wikipedia - soname，.so文件中的SONAME字段是“基本兼容版本”。从我在上面的问题中发现的行为可以清楚地看出，ld将SONAME插入到链接到共享库的文件中 - 而不是ld命令中指定的文件名。

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

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

为什么链接器会更改共享库名称？

1 个答案: