linker name, soname, real nameの使い分けについて

Question

linuxにおける共有ライブラリの運用について教えてください。
linuxでは共有ライブラリを管理するためにlinker name, soname, real nameの３つの名前を使うと聞きました。

リンク先の記述を見て下記のように運用すると理解しました。

• バイナリ互換性のあるバージョン

旧バージョンに対して、real nameは異なるが、sonameは同じ。
（real nameのマイナー番号かリリース番号を上げ、sonameのバージョン番号は変更しない。）

• バイナリ非互換となったバージョン

旧バージョンに対して、real name, sonameの両方が異なる。
（real name/soname両方のバージョン番号を上げる。）

• ldconfigを実行

共有ライブラリ・ファイルに記録されているsonameを使ってシンボリック・リンク・ファイルが生成され、それはreal nameのファイルを指す。

ということは、その共有ライブラリを使う側はsonameを指定してリンク指示すれば、バイナリ互換性のある共有ライブラリにリンクでき、皆幸せになれそうです。（Windowsも同様な仕組みを設ければ良いのに。）

質問です

1. linker nameにはバージョン番号を含まないようです

上記リンク先ではlinker nameにはバージョン番号を含んでいません。
他のサイトでもそのような解説でした。ここもそうです。
しかし、バイナリ非互換な共有ライブラリにリンクするのはあり得ないように感じます。
何故、linker nameにはバージョン番号を含まないのでしょうか？
このように書いているサイトしか見つからないので自信はないのですが、リンク先サイトのミスですよね？

1. 同じsonameに対して複数のreal nameの必要性

互換性があるので単純に共有ライブラリを上書きすれば、sonameによるシンボリックリンクは不要な気がします。（Windowsでも、そのような運用であれば可能なので検討してます。)
ただ、古い共有ライブラリ・ファイルを残したままバージョンアップできれば、新しいもので何か不具合が起きた時、古いものへ簡単に戻せます。
これがsonameに対して複数のreal nameを対応させる主なメリットでしょうか？ また、他にも何か目的（メリット）はあるでしょうか？

私なりの結論(2017/01/19追記)

Windowsでは大変頭の痛い非互換なバージョンのライブラリへのリンクを回避できるスマートな技術としてsonameとldconfigがlinuxには存在しています。
そして、David A. Wheeler氏がその折角の技術を無にして、互換性を問わず最新のライブラリとリンクさせるバージョン番号のないlinker nameを提案されています。

その理由が下記のように書かれています。

ほとんどの場合において、ライブラリを更新したら、リンク時にそれを自動的に利用したいと思うでしょうから

アプリケーションを更新した時は最新版を使いたい人がほとんどですね。
ライブラリを更新した時に、それを使うアプリケーションが起動しなくなるリスクを冒したい人はほとんどいないと思います。

「前者と混同し、かつ、linuxでは対策されているのであまり発生しない後者の問題を見落とした結果、バージョン番号のないlinker nameが提案され、それをなんとなく納得してしまった人が多数いる」を、現時点での私なりの結論と致します。

とはいえ、自分で書いておきながら、このような間違いを多くの人が冒していると言う説には無理を感じます。
もし、linker nameが存在した方がよい理由をご存知の方、もしくは、推測のある方がいらっしゃいましたら、教えて頂けると幸いです。
逆に、「libtoolを使っていないライブラリの場合、バージョン番号のないlinker nameによるシンボリックリンクを生成するインストーラなんて実際にはないよ」と言う情報があると大歓迎です。

Answer 1

内部の仕組みはよくわからないながら、ライブラリを作るときは一応「バージョン」を気にしています。

たとえばGNU libtoolの-version-infoオプションは、より明確にABIの (後方) 互換性を管理するためのものになっています (オブジェクトファイルの名前と異なる採番ルールを用いている理由はわかりませんが)。こちらの情報の方が、ライブラリの「バージョン」としてはファイル名よりもより本質的な情報だと思われます (詳細はマニュアルの「バージョニング」節を参照)。

この「バージョン」は二度参照されると考えられます。一度はビルド時、リンクされるライブラリを決定した際に。二度目は実行時、ダイナミックリンクが実行される際に。つまり、実行ファイルに記録されたABIバージョンが、実行時に見つかるライブラリのABIバージョンと一致しなければ、ダイナミックリンクは失敗します。複数の「バージョン」のライブラリが使われ得るのなら、そのいずれをもインストールしておけばいいです (ファイル名が違うので、可能です)。

そういうわけで、ビルド時にはlinked nameで識別されるライブラリが見つかりさえすればよい、
ということにしているのだと考えます。

Comments

[KSwordOfHaste]

素朴な理解しかないのにうっかり回答してしまいましたがおかげさまで勉強させてもらってます。libtoolの記事を読んでみたところこのツールを理解すると仕組みの勉強になるように感じました。情報ありがとうございます。

[ikedas]

いえいえ。わたしもよく考えてみたことがなかったので、勉強になります。ちょっと修正しました。

[Chironian]

回答、ありがとうございます。

libtoolは、リンク先解説のバージョン管理方式とはまた別のバージョン管理方式のように感じました。

共有ライブラリのバージョンをCURRENTとREVISIONの２つで管理し、そのライブラリがどこまで古いバージョンと互換なのかをAGEで管理すると理解しました。そして、恐らくファイル名の最後にCURRENTとREVISIONとAGEをドットで区切って記録するような印象です。であれば、linker nameをバージョン番号無しとして、最新版へリンクしておけば、自動的に適合するバージョンをサーチしてくれると言うことでしょうか？

これがlinuxの常識であれば納得です。
ただ、どうも違うような気がしてます。リンク先はどこもlibtoolに言及してませんでした。そして、その仕組みであればsonameにはバージョン番号無しのものを設定するべきのように感じるのです。

libtoolで運用する場合、一般的なバージョン番号と異なるバージョン番号も管理しないといけなくなるので、便利そうに見えて、実は意外に使い勝手は悪そうな印象も受けます。

[ikedas]

んー、いろいろちょっと違うような。うまく伝わらなくてすみません。

ちなみに、Linuxの常識ではなく、多くのLinuxでもユーザランドで採用しているGNUツールチェインの仕様でしょうね。ですからLinux以外の、*BSD等でも同様です。

とまれ、想像まじりでこれ以上お答えするのは難しいので、きちんと調べてみようと思います。いつまでとは言えないので、こちらはお気遣いなく進行下さい。

[Chironian]

了解です。

１つだけ教えてください。
libtoolは大半のプロジェクトで使われているようなツールでしょうか？もし、そうであれば私も使えるようにならないとなと思います。
そうでなくて、使わないプロジェクトも多いようなら、私も使わないと思います。正直なところ、複数のバージョン番号をきちんと管理できる自信がないし、ldconfigの仕組みは十分に有用な気がしてます。
情報が少ないので、たぶん後者と思うのですが。

[ikedas]

Autotools (autoconfやautomake) を使ってシェアドライブラリのパッケージを開発するときは、libtoolを使うのが通例と思います (libtoolを単独で使うことはあまりないと思います)。つまり、ビルドのときにconfigureスクリプトを実行するタイプのパッケージで、ライブラリであるものは、たいていが使っていると思っていいです。

libtoolの利点は、autotoolsの提供するビルドシステムに統合できる点、また何よりも、そのライブラリをリンクする別のパッケージを開発する際にもシェアドライブラリの処理のためにプラットフォーム依存のコードを書かなくてよくなる点です。それに、継続的な開発ではABIのバージョン管理も必要になりますから、一貫した単純な (と思います) 方法でそれができることには意味があります。

しかし、たとえば特定のプラットフォームだけをターゲットにするような製品であったりすれば、上のような機能はたしかにオーバースペックかもしれません。

[Chironian]

なるほど。了解です。

確かに-fPICでははまりました(http://qiita.com/Chironian/items/efdc1f6937fcb08ce164)のでAutotoolsのメリットはありそうですね。

でも、既に私はマルチ・プラットフォーム対応のためにCMakeを使っているので、今からAutotoolsへ移行するのは厳しそうです。
OpenCVやllvm、boost等、結構メジャーなFOSSプロジェクトでもconfigureスクリプトでないものも少なくないので、このまま行こうと思います。

情報、ありがとうございました。

Answer 2

1. linker nameにはバージョン番号を含まないようです

ライブラリーの利用者（プログラマー）はインストールされている最新のバージョンを使おうという場合もあり得ると思います。下記のリンクにそうしたことについて簡単な記述があります。つまりはそういう目的で使うためにlinker nameがあるように思います。

3.1.1. 共有ライブラリ名

1. 同じsonameに対して複数のreal nameの必要性

これがsonameに対して複数のreal nameを対応させる主なメリットでしょうか？

そういうこということだと思います。

Windowsも同様な仕組みを設ければ良いのに

.NETなんかはそういう仕組みに近い方式を採用していると思います。

ちなみにインターネットにある様々なページの信頼度は様々です。情報はなるべく「より発信源に近いところ」をみると確実度が高いと思います。「調べたことを個人的なメモとして残しておいた」的なページも有用なことは多いでしょうが、自分は沢山のページがヒットしそうな情報はなるべく大元に近いページを参照するようにしたほうがいいと思います。つまりsomeone.comよりlinux.or.jpやor.jpの方を見てみるという配慮もあったらいいと思います。

Comments

[Chironian]

回答、ありがとうございます。

linux.or.jpが落ちているようでまだ見に行けていません。

> ライブラリーの利用者（プログラマー）はインストールされている最新のバージョンを使おうという場合もあり得ると思います。

開発中のソフトや他の人へ配布しないソフトの場合はその通りと思いますが、例えば、他の人Aへ配布するソフトでそれをやるのは無茶なように感じます。
Aが受け取ったソフトをバージョンアップしないまま、共有ライブラリだけを非互換なバージョンへバージョンアップすることは普通にあると思います。sonameでリンクしておけば、そのような事態が生じても非互換問題は発生しないので安心です。何故にその仕組みを無にするのか不思議なのです。

> .NETなんかはそういう仕組みに近い方式を採用していると思います。

.NETはCOMの延長線上にあると理解しています。昔COMをVC++（非CLI）から使ったことがあるのですが、泣きたくなるほど苦労しました。linuxの単純明快な仕組みとは比べられないように感じます。

> 「より発信源に近いところ」をみると確実度が高いと思います。

その通りですね。疑義を感じる場合はできるだけそのようにしているのですが、linuxには詳しくないのでなかなか。linux.or.jpの存在を教えて頂きありがとうございます。

[KSwordOfHaste]

Chironianさんの質問だったことに今気づき少々あせっております・・・(..;
> 他の人Aへ配布するソフトでそれをやるのは無茶なように感じます。
確かにおっしゃる通りと思います。自分用のプログラムを作る（例えば私のようなアマチュアが）ローカルな環境でビルドする際に手軽というだけの話なんでしょうね。linux.or.jpの3.1をみたのですがある人がlinkerのconfigurationにデフォルトではlinker nameを付けないということが載ってました。つまりはChironianさんがおっしゃるとおりの考え方が普通だということだと思いました。

.NETについては「互換性を考慮した仕組みがWindowsにも組み入れられた」という記事をみてなるほどと思った程度の認識しかありませんでした。おっしゃるとおりlinuxのsoのsynbolic linkの方がプログラマーにとって単純・調べやすい・わかりやすいという点は同意です。
>より発信源に近い
自分もよく個人ブログの情報にふりまわされちゃってます。なんだか偉そうなことを言ってしまい冷汗がでてます。そこはご容赦いただければと存じます。

[Chironian]

>> 他の人Aへ配布するソフトでそれをやるのは無茶なように感じます。
> 確かにおっしゃる通りと思います。

やはりそうですよね。

> ある人がlinkerのconfigurationにデフォルトではlinker nameを付けないということが載ってました。

たぶん、ldconfigですね。デフォルトでつけないのは納得できます。
sonameでシンボリック・リンクを自動生成するって簡単なのに非常に優れた仕組みと思います。
この仕組みがWindowsにも欲しいです。

やっとlinux.or.jpアクセスできました。
ここもlinker nameにバーション番号を含めない方が一般的な使い方であるかのように記載されてました。

> ほとんどの場合において、ライブラリを更新したら、リンク時にそれを自動的に利用したいと思うでしょうから

互換性を維持していないライブラリも含めて自動的にリンクしたい人がほとんどという見解にはたいへん驚きですが、そのような見解が「主流」なのですね。

本家stackoverflowにも似たやりとりがでてきたので、国内だけの見解ではなさそうです。
http://stackoverflow.com/questions/4685493/gcc-linking-to-a-shared-objects-linker-name
ここに教えていただいた日本語ページの恐らく原文へのリンクがありました。
http://www.tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN46
なるほど、David A. Wheelerさんと言う方の見解が広まっているのかも知れませんね。

> 自分もよく個人ブログの情報にふりまわされちゃってます。なんだか偉そうなことを言ってしまい冷汗がでてます。そこはご容赦いただければと存じます。

いえいえ、私は英語が苦手なのでどうしても日本語情報に頼ることが多いので、日本語のlinux情報源を教えて頂き、本当にありがたいです。

David A. Wheelerさんはそれなりの方と思います。もう少し他の方の意見も聞きたいので、もうしばらくオープンさせて下さい。

[KSwordOfHaste]

> 互換性を維持していないライブラリも含めて自動的にリンクしたい人がほとんど
既にメジャーバージョンが変わっているものが複数存在していても時代の流れに従って緩やかに新しいバージョンのみが生き残っていくということはあると思います。ただ「ほとんどの人がメジャーバージョンを気にしない」というのは確かに意外な気がします。「ほとんど」というのがソフトウェアプロバイダーではない一般の開発者やアマチュアを全部含めたのであれば「ほとんど」ということになるのかも知れませんが、例えば顧客へ納入するソフトウェアを開発している方々に対象をしぼれば「メジャーバージョンを気にするのは常識」に思えますよね。

[Chironian]

ですよね。
一般ユーザでさえ、使っているソフトが動かなくなったら嫌なので、非互換なライブラリへのリンクを望む人は「ほとんどいない」と思うのですよ。

そのようなDavid A. Wheelerさんの見解を支持している人が多数いるということは、逆に私が知らないlinux上の何かがあるかも知れないと懸念しています。一人二人くらいなら無視するのですが、かなり多いというか、見つけた全ての人たちが皆支持しているので、無視するには怖いのです。

> 時代の流れに従って緩やかに新しいバージョンのみが生き残っていく

DepricatedなAPIが削除されるような流れですかね。そのようなバージョンアップしかしないことが一般的になっているのであればあり得るかも。非互換なバージョンアップについて何か暗黙の了解があるのであれば、ライブラリの開発者側はそれはちゃんと把握しておかないとやばいですね。

[KSwordOfHaste]

自分の方が勉強させていただいたのでBestAnswerは心苦しい感じです。自分としてはopen/commercialのいずれにせよ古いバージョンはサポートが止まる運命にあるので大きな流れとしてはlinker nameが主たるキーとして残る気はするのですが、開発者の興味の焦点はどこにあるかの実情にはまだ疑問がある状態です。Chironianさんやikedasさんが考えておられるようなバージョン互換に注意するのが多数派でないとしたらなんだかもやもやします。アマチュアの立場としては主としてOSSのcontributorがどう考えているか今後注意しようと思いました。つたない回答で失礼しました。