なぜリンカは共有ライブラリ名を変更しますか？

Question

'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私はlibao-oboe.soが含まれていないものに-Lのパスを変更した場合、リンカは/usr/bin/ld: cannot find -la-oboeを返すために正しくオプションを渡しているように見えます。要求されたライブラリの名前がlibのものと異なるように変更すると、リンカはエラーも返します。

問題は、実行時にローカルライブラリがロードされないことです。 lddは、node-gyp出力ファイルが指定されたファイルを参照していないことを示しています。別の名前のライブラリを参照しています - /usr/lib/liboboe-1.0.so.1。 ldd出力の2行目を参照してください。

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は、ldコマンドで指定されたファイル名ではなく、共有ライブラリにリンクされているファイルにSONAMEを挿入します。

.soファイルの名前を変更してもSONAMEは変更されないため、名前が変更されたファイルにリンクされた実行ファイルは、ファイル名ではなくSONAMEフィールドで指定されたライブラリをロードしようとします。

解決方法は、ファイルの名前を変更しないことでした。