[ruby-dev:4768] Re: shared library

福間@福岡 です。

記事 <[e-mail]> において、
EGUCHI Osamu <[e-mail]> さんは書きました :

> 逆読みすると、インターフェースに変更のないときは、
> パッケージのバージョンが上がっても、minor は増やさなくても
> 良いと言う事ですね。

そういうことになるでしょうね。

> 福間> ・ELF環境の場合(FreeBSD 3.x以上での標準設定)

> こちらは、symlink 元 の lib<name>.so.<version> を aout の物と
> 同名にしてしまうのも、可能ですね。
> (aout は別ディレクトリにインストールされるので)

そういう手もあるのですが、FreeBSDハンドブック(の ELF対応のportを作る
ときの注意点を解説した項)によると

| 共有ライブラリのバージョン
|   ELF の共有ライブラリは, "libfoo.so.M" という名前になっていなければ
|   なりません. ここで M は単一のバージョン番号を表します. 一方 a.out の
|   ライブラリは "libfoo.so.M.N" という名前で, M はメジャーバージョン
|   番号, N はマイナーバージョン番号になっている必要があります. これらを
|   混同しないでください. "libfoo.so.N.M" という名のELF 共有ライブラリや 
|   "libfoo.so.N" という名の a.out 共有ライブラリ(あるいはシンボリック
|   リンク) は 絶対にinstallしないでください.

| PLIST は, a.out のマイナー番号が0であれば, 短い (ELFの) 共有
| ライブラリの名前を含み, さもなくば長い (a.outの) 名前を含んでいる
| 必要があります. bsd.port.mk は 自動的に, PORTOBJFORMAT が aout で
| あれば, `.0' を 短い共有ライブラリの名前の行に付け加え,
| PORTOBJFORMAT が elf であれば, マイナー番号を長い共有ライブラリの
| 名前から削除します.
| 
| ELF システムで 2 つのバージョン番号を持つ共有ライブラリをインストール
| したり, aout システムで 1 つのバージョン番号しか持たない共有
| ライブラリをインストールするのが避けられない場合 (例えば他の
| オペレーティングシステム用の互換ライブラリをインストールする port
| など), FILTER_NO_SHLIBS 変数を定義すれば, 前節で説明されている PLIST
| 編集の機能が停止されます.

# PLIST: portからインストールされるファイルの一覧(package list)
# PORTOBJFORMAT ||= `objformat` || aout

ということなので、どうしようもない時の最終手段と考えたほうが
いいでしょう。

# 仕様としては、sonameさえ正しく設定されていれば
# libfoo.so -> libbar.so.1.2.3.4.5 というリンクを張って
# -lfoo でリンクしても、うまく動作はするはずです:)

> 私の考えでは、/etc/objformat での aout/elf の変更は
> 透過的にコンパイル／リンクで扱われ、ファイルの命名規則や
> インストール先を工夫する必要があると思っていました。

ん?  そういうことですよ?

  $ objformat                           ←デフォルトはELF
  elf
  $ gcc foo.c                           ←コンパイルすると
  $ file a.out                          ←ELFバイナリができる
  a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), \
  dynamically linked, not stripped
  $ export OBJFORMAT=aout
  $ objformat                           ←デフォルトをa.outにしてみる
  aout
  $ gcc foo.c                           ←同じようにコンパイルすると
  $ file a.out                          ←こんどはa.outバイナリになる
  a.out: FreeBSD/i386 compact demand paged dynamically linked executable \
  not stripped
  $ gcc -elf foo.c                      ←でも明示的に指定してやれば
  $ file a.out                          ←ちゃんとELFバイナリができた
  a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), \
  dynamically linked, not stripped

> 福間> # いまなら「a.outはサポートしない」という選択肢もありうるけど…
> 
> あさみさんから、2.x の ports-current での正式サポート終了が
> アナウンスされたのではありますが、3.0.x でも aout は
> 使えるわけだし、インストールベースでは 2.x がしばらく多そうなので、
> 悩ましいですね。

# 2.x -> 2.2.x, 3.0.x -> 3.x ですね

まあ、もうしばらくは2.2系を使い続けたいというひとも多いでしょうし
(2.2-currentが2.2-stableと3.0-currentに分岐したときと同じように)、
3.0-stableは重要なサーバなんかに使うにはまだ少し早いかなという気も
しますし(Linux 2.2.xと似たような状況ですね)、可能ならa.out環境でも
使えるようにしておいたほうが幸せでしょう。

> major を、パッケージ番号とは切り離して管理する
> 必要を強く示唆していますね。

わたしもそう思います。

特に1.3のような開発系ブランチの場合、同一ブランチ(あるいは
同一バージョン番号)内でもインターフェイスの変更が起こる場合が多々
ありますので、ライブラリのバージョン番号は独立して管理しておかないと
複数バージョン間での問題が発生する可能性が高いでしょう。

# FreeBSDなどで、うっかり libruby.so.1(.3) なんていう名前を付けて
# しまうと大変なことになる…

> 福間> ELF環境だと、拡張モジュールを作るときにも -Wl,-soname,hoge.so なんてのが
> 福間> 渡ってしまいますが、実用上問題はないでしょう。たぶん。
> 
> これ不要ですか？
> 拡張モジュールから、 libruby.so の関数を呼ぶので必要かと思ってました。

sonameが必要なのは

  1. リンカが実行形式を作るときに -lfoo と言われたので libfoo.so を
     リンクしようとした
  2. このとき、libfoo.so は実際には libfoo.so.1 へのシンボリックリンク
     だった
  3. libfooをバージョンアップしたので、libfoo.so のリンク先を libfoo.so.2
     へと変更した
  4. この状態で、1で作ったバイナリを実行した
  5. ダイナミックリンカが libfoo.so をロードしようとした
  6. ところが、libfoo.so の実体は、コンパイルしたときとは仕様の違う
     libfoo.so.2 になってしまっているので、プログラムがうまく動作しない

という問題を解決するためですので、単に(実行時に)指定されたライブラリを
(実行時に)ロードするだけなら必要は無いと思います。

まあ、あっても害になるようなものではありませんので、あまり気にせずに
そのまま残しましたが。
---
 Yasuhiro Fukuma (福間 康弘) as Yasu.F @ Kitakyushu.Fukuoka.Japan
 Web site: http://www8.big.or.jp/~yasuf/
 “君の主人公は君だ。”