回答編集履歴

3

あ、そこか。追記

2017/01/16 12:21

投稿

ikedas
ikedas

スコア4335

test CHANGED
@@ -2,7 +2,7 @@
2
2
 
3
3
  たとえばGNU libtoolの-version-infoオプションは、より明確にABIの (後方) 互換性を管理するためのものになっています (オブジェクトファイルの名前と異なる採番ルールを用いている理由はわかりませんが)。こちらの情報の方が、ライブラリの「バージョン」としてはファイル名よりもより本質的な情報だと思われます (詳細はマニュアルの「バージョニング」節を参照)。
4
4
 
5
- この「バージョン」は二度参照されると考えられます。一度はビルド時、リンクされるライブラリを決定した際に。二度目は実行時、ダイナミックリンクが実行される際に。つまり、実行ファイルに記録されたABIバージョンが、実行時に見つかるライブラリのABIバージョンと一致しなければ、ダイナミックリンクは失敗します。
5
+ この「バージョン」は二度参照されると考えられます。一度はビルド時、リンクされるライブラリを決定した際に。二度目は実行時、ダイナミックリンクが実行される際に。つまり、実行ファイルに記録されたABIバージョンが、実行時に見つかるライブラリのABIバージョンと一致しなければ、ダイナミックリンクは失敗します。複数の「バージョン」のライブラリが使われ得るのなら、そのいずれをもインストールしておけばいいです (ファイル名が違うので、可能です)。
6
6
 
7
7
  そういうわけで、ビルド時にはlinked nameで識別されるライブラリが見つかりさえすればよい、
8
8
  ということにしているのだと考えます。

2

Typo\^2

2017/01/16 12:21

投稿

ikedas
ikedas

スコア4335

test CHANGED
@@ -4,6 +4,6 @@
4
4
 
5
5
  この「バージョン」は二度参照されると考えられます。一度はビルド時、リンクされるライブラリを決定した際に。二度目は実行時、ダイナミックリンクが実行される際に。つまり、実行ファイルに記録されたABIバージョンが、実行時に見つかるライブラリのABIバージョンと一致しなければ、ダイナミックリンクは失敗します。
6
6
 
7
- そういうわけで、ビルド時にはsonameで識別されるライブラリが見つかりさえすればよい、
7
+ そういうわけで、ビルド時にはlinked nameで識別されるライブラリが見つかりさえすればよい、
8
8
  ということにしているのだと考えます。
9
9
 

1

Typoだな

2017/01/16 12:09

投稿

ikedas
ikedas

スコア4335

test CHANGED
@@ -1,6 +1,6 @@
1
1
  内部の仕組みはよくわからないながら、ライブラリを作るときは一応「バージョン」を気にしています。
2
2
 
3
- たとえばGNU libtoolの-version-infoオプションは、より明確にABIの (方) 互換性を管理するためのものになっています (オブジェクトファイルの名前と異なる採番ルールを用いている理由はわかりませんが)。こちらの情報の方が、ライブラリの「バージョン」としてはファイル名よりもより本質的な情報だと思われます (詳細はマニュアルの「バージョニング」節を参照)。
3
+ たとえばGNU libtoolの-version-infoオプションは、より明確にABIの (方) 互換性を管理するためのものになっています (オブジェクトファイルの名前と異なる採番ルールを用いている理由はわかりませんが)。こちらの情報の方が、ライブラリの「バージョン」としてはファイル名よりもより本質的な情報だと思われます (詳細はマニュアルの「バージョニング」節を参照)。
4
4
 
5
5
  この「バージョン」は二度参照されると考えられます。一度はビルド時、リンクされるライブラリを決定した際に。二度目は実行時、ダイナミックリンクが実行される際に。つまり、実行ファイルに記録されたABIバージョンが、実行時に見つかるライブラリのABIバージョンと一致しなければ、ダイナミックリンクは失敗します。
6
6