共有オブジェクトのバージョンアップ

共有オブジェクトの使用可能インタフェースを決定して、mapfile とリンカーの -M オプションを使用すれば対応するバージョン定義を作成できます (この mapfile 構文の説明については 、「追加シンボルの定義」を参照)。

次の例は、共有オブジェクト libfoo.so.1 にベンダー公開インタフェースを定義しています。

$ cat mapfile
SUNW_1.1 {                   # Release X.
        global:
                foo2;
                foo1;
        local:
                *;
};
$ cc -G -o libfoo.so.1 -h libfoo.so.1 -z text -M mapfile foo.c

ここで、大域シンボル foo1 と foo2 は、共有オブジェクト公開インタフェース SUNW_1.1 に割り当てられています。入力ファイルから提供された他の大域シンボルはすべて、自動縮小命令「*」によって局所範囲に縮小されています (「シンボル範囲の縮小」を参照)。

各バージョン定義の mapfile エントリには、更新のリリースまたは日付を反映するコメントを付けてください。この情報は、たとえば複数の開発者によって行なわれた 1 つのオブジェクトに対する複数の変更を 1 つのバージョン定義にまとめて、ソフトウェア製品の一部として共有オブジェクトを配布するのに適切なものに調整するときに役立ちます。

既存の (非バージョンアップ) 共有オブジェクトのバージョンアップ

既存の非バージョンアップ共有オブジェクトをバージョンアップするには、特に注意が必要です。これは、以前のソフトウェアリリースで配布された共有オブジェクトが、その大域シンボルのすべてを、他のものと結合できるようにしているためです。共有オブジェクトの意図したインタフェースを判定できる可能性はありますが、ソフトウェア開発者が発見して他のシンボルに結合した可能性もあります。したがって、シンボルを削除すると、新しくバージョンアップされた共有オブジェクトの配布時にアプリケーションに障害が生じる場合があります。

既存の非バージョンアップ共有オブジェクトの内部バージョンアップは、既存アプリケーションを破壊することなく、インタフェースを判定して適用できる場合に実現できます。実行時リンカーのデバッグ機能は、各種のアプリケーションの結合条件を検査するために役立ちます (「デバッギングエイド」を参照)。ただし、この既存結合条件の判定は、共有オブジェクトを使用するすべてのプログラムがわかっているということを前提としています。

既存の非バージョンアップ共有オブジェクトの結合条件を判定できない場合は、新しいバージョンアップ名を使用して、新しい共有オブジェクトファイルを作成する必要があります (「バージョンアップファイル名の管理」を参照)。すべての既存アプリケーションの依存関係を満たすには、この新しい共有オブジェクトだけでなく、元の共有オブジェクトも配布する必要があります。

元の共有オブジェクトの実装を一切変更しない場合は、共有オブジェクトのバイナリをそのまま配布するだけで十分でしょう。しかし、元の共有オブジェクトを更新する必要がある場合 (たとえば、パッチや、新しいプラットフォームとの互換性を保つための実装の変更など) は、代替ソースツリーから共有オブジェクトを作り直した方がいいでしょう。