Gauche:ABICompatibility

Shiro(2009/11/23 18:21:34 PST): ABI互換性について気をつけることメモ。

目的

Gaucheのmicro version up (X.Y.Z の Z が変わる変更) については、 Gaucheを入れ替えるだけで拡張ライブラリなどlibgauche.soに依存するものはそのまま使えるようにしたい。

考慮すべきは以下の点。

ライブラリのサーチパス: 今は.soのサーチパスにバージョンがフルで埋め込まれちゃってるので拡張ライブラリの.soが見つけられなくなる。
拡張ライブラリからのlibgaucheのバージョンチェック: 拡張ライブラリは、ロードされた際にロード主が自分とABIコンパチであるかどうかチェックしたい。今はノーチェック。
mainからのlibgaucheのバージョンチェック: libgaucheをリンクする組み込みライブラリが、実行時に動的リンクされたlibgaucheとABIコンパチであるかどうかチェックしたい。今はScm_Initでバージョンの完全マッチをチェックしてるので、 micro versionが違うと実行できない。

新しいAPIの追加は許す。つまり、コアを 0.9 -> 0.9.1 にした時:

0.9向けにコンパイル済みの拡張ライブラリやmainはそのまま動く
0.9.1向けにコンパイルし直せば0.9.1で追加されたAPIが使える。そうした拡張ライブラリやmainは0.9コアでは動かない。

ライブラリのロードパス

一番簡単なのはロードパス中のバージョン番号埋め込みをmajorとminor (X.Y) だけにすることだな。

ただ、この場合、既にGaucheが入ってるところに上書きインストールすると、既に ${exec_prefix}/lib/gauche/X.Y/ 以下に作られている階層に上書きすることになる。それはそれでちょっと気持ち悪い。特に、何か問題が出てダウングレードしたい場合に困りそうだ。 (この階層にはGauche-gl等コア以外のモジュールの.soも入ってるので、どれとどれを旧バージョンに戻したら良いのかすぐにわからない、とか)

バージョンX.Y.ZのコアはZを一個づつ減らしたパスを全部load-pathに入れちゃうって手もある。これだと今と同じディレクトリ構造で、さらに旧バージョン向けにコンパイルされた拡張ライブラリも見える。でもmicro versionが増えるとロードパスがやたらに長くなるし、うっかり古いの消したら今使ってる拡張ライブラリも消えちゃったってことになりそうだ。

少々強引なハックだけれど、Gaucheコアインストール時に旧バージョン用のディレクトリがあったらコア以外の.soを新バージョンディレクトリからハードリンクしてしまうってのはどうだ。インストール時の操作がややこしくなるが、特に問題は生じないような気もする。 (ハードリンクが使えないOSではコピーすることになるのがちょっと嫌かもしれないが)。これを試してみよう。

いや、だめだ。拡張パッケージが何らかのパッケージマネージャで管理されてる場合、コピーやハードリンクしちゃうとパッケージマネージャからのアンインストールでファイルが消えてくれなくなる。

要求事項をまとめてみる。

Gauche本体のファイルは本体バージョンごとに分けてインストールしときたい。
拡張モジュールのファイルはABI versionにつき一ヶ所。コピーとかリンクとか無し。
探しに行くディレクトリが際限無く増えてくのはやだ。

ってことは、アーキテクチャ依存ファイルの置き場をこうしてみたらどうだろう。

現在:
- ${exec_prefix}/gauche/${gauche_version}/${arch}/* ;; *.so
- ${exec_prefix}/gauche/${gauche_version}/include/* ;; *.h
- ${exec_prefix}/gauche/site/${gauche_version}/${arch}/* ;; *.so
- ${exec_prefix}/gauche/site/${gauche_version}/include/* ;; *.h

案:
- ${exec_prefix}/gauche/${ABI_version}/${gauche_version}/${arch}/* ;; 本体の*.so
- ${exec_prefix}/gauche/${ABI_version}/${gauche_version}/include/* ;; 本体の*.h
- ${exec_prefix}/gauche/${ABI_version}/site/${arch}/* ;; 本体以外の*.soなど
- ${exec_prefix}/gauche/${ABI_version}/site/include/* ;; 本体以外の*.h

今はGauche-glのファイルとかがsiteじゃない方(本体と一緒)に入ってるけど、本体以外のは全部siteに入れることにする。

アーキテクチャ非依存の方はディレクトリ構成は今までどおりとして、本体以外のは全部site以下に入れる、という点だけ変更する。

${datadir}/gauche/${gauche_version}/* ;; 本体の*.scm
${datadir}/gauche/site/* ;; 本体以外の*.scm

拡張ライブラリからのバージョンチェック

初期化ルーチンがマクロSCM_INIT_EXTENSIONを呼んでるので、マクロ定義をちょっといじってABI versionのチェックを忍ばせることはできそうだ。

mainからのバージョンチェック

Scm_Init()に渡してるsignatureにバージョンが含まれるので、それを解析してチェックする。

gauche versionとabi version

ABI_versionはどのように指定するのが良いか。

(案1) gauche_versionのmajor.minorに合わせる。例えばgauche versionが0.9.2なら ABI versionは0.9, gauche versionが1.0.13ならABI versionは1.0
(案2) ABI_versionが変わればlibgaucheのsonameも変わる。sonameに含めるインタフェースバージョン番号は1桁だから、ABI_versionもそっちに合わせちゃう。 gauche version 0.9.xの間はABI_version=0。gauche version 1.0になったら ABI_version=1、gauche version 1.1になったらABI_version=2、and so on.

案1の方が一見わかりやすそうではあるのだけれど、よく考えるとそうでもない。

アーキテクチャ依存ファイル置き場のパスにはABI_versionとgauche_versionが含まれるのでまぎらわしい。
1.0と1.1でABIを変えるならsonameも変えないとならないので、libgauche.so.X.Y.Z のX.Y.Zがgauche_versionと一致するわけではない。無関係に単調増加する番号を振るか、1.0.xのABIは100、1.1.xのABIは101、1.13.xのは113、みたいにエンコードするか。
もし1.0の手前にプレリリースとして0.99とかを出したいと思った場合、ABI versionとの齟齬が発生する。

まあsonameについては、gauche_version X.Yをlibgauche-X.so.Y にマップしてしまう、という手が無くはない。

案2については、プレリリースの0.99でABIバージョン1を実装する、というような融通がきかせられるという利点がある。(あと、どうしてもmicro version upで ABIを変更せざるを得ない止むに止まれぬ事情があった場合、とか。)

折衷案でこういうのはどうだ(案3)。

ABI_versionは原則としてgauche_versionのmajor.minorと一致。
アーキテクチャ依存ファイル置き場のパスを
```
${exec_prefix}/gauche-${ABI_version}/...
```
とする。例えば0.9の間は/usr/lib/gauche-0.9/...。1.0になったら/usr/lib/gauche-1.0/...。
ライブラリのsonameはlibgauche-X.Y.so.0 とする。
ライブラリのrealnameはlibgauche-X.Y.so.0.Z とする。Zはmicro version。
特例として、0.99.wみたいなプレリリースの場合、ABI versionは先取りして1.0とし、ライブラリのrealnameはlibgauche-1.0.so.0.0.w という具合にする。1.0正式リリースの際はlibgauche-1.0.so.0.0.5とかになるかもしれない。

major.minorまでをそんなに頻繁にアップデートするとも思えないので、 ${exec_prefix}以下にディレクトリが無闇に増殖してしまうってことは多分ないだろう。