第 5 章 アプリケーションバイナリインタフェースとバージョン管理
リンカーによって処理される ELF オブジェクトには、他のオブジェクトを結合できる多数の大域シンボルがあります。これらのシンボルは、オブジェクトのアプリケーションバイナリインタフェース (ABI) を記述するものです。オブジェクトの展開中、このインタフェースは、大域シンボルの追加または削除が原因で変更されることがあります。また、オブジェクト展開には、内部実装の変更が関与することがあります。
バージョン管理とは、インタフェースや実装状態の変更を示すためにオブジェクトに適用できるいくつかの手法のことをいいます。これらの手法を使用すると、下位互換性を保ちながらオブジェクト制御による展開を行うことができます。
この章では、オブジェクトの ABI の定義方法について説明し、このインタフェースに対する変更によって下位互換性が受ける影響を分類します。また、インタフェースと実装状態の変更を新しいリリースのオブジェクトに組み込むためのモデルを示します。
この章では、動的実行可能プログラムと共有オブジェクトの実行時インタフェースを中心に説明します。これらの動的オブジェクト内での変更を記述して管理するために使用される手法は、一般的な用語で説明してあります。共有オブジェクトに適用される命名規約とバージョン管理シナリオの共通セットは、付録 B 「バージョン管理の手引き」 に示してあります。
動的オブジェクトの開発者は、インタフェース変更の結果に注意し、特に以前のオブジェクトとの下位互換性を維持するという点で、これらの変更の管理方法を理解する必要があります。
動的オブジェクトによって使用可能になった大域シンボルは、オブジェクトの公開インタフェースを表わします。リンク編集の最後でオブジェクトに残る大域シンボルの数は、公開したいと望む数を超える場合がよくあります。これらの大域シンボルは、そのオブジェクトの構築に使用された再配置可能オブジェクトの間で必要な相互関係から引き出されます。これらの大域シンボルは、オブジェクト自体の非公開インタフェースを表わします。
オブジェクトのバイナリインタフェースを定義する前に、まず、作成されるオブジェクトから公開して使用できるようにする大域シンボルを決定する必要があります。これらの公開シンボルは、リンカーの -M オプションと関連の mapfile を最終リンク編集の一部として使用することによって確立できます。この手法は、シンボル範囲の縮小に説明されています。この公開インタフェースは、1 つまたは複数のバージョン定義を作成中のオブジェクト内に確立します。これらの定義は、オブジェクトの進化に合わせて新しいインタフェースを追加する際の基礎となります。
次の節は、この初期公開インタフェースに基づいて説明されています。最初に、インタフェースへの各種の変更をどのように分類すると、適切な管理を行えるかを理解しておく必要があります。
インタフェースの互換性
オブジェクトにはさまざまな変更を加えることができます。これらの変更は、単純に次の 2 つのグループに分類することができます。
-
互換性のある変更。これらの変更は、今まで使用できたインタフェースがすべてそのままの状態で残されるという点で付加的なもの
-
互換性のない変更。これらの変更は既存インタフェースを変更したため、そのインタフェースの既存ユーザーはそれを使用できないか、または動作が異なる
次のリストは、共通のオブジェクト変更のいくつかを分類しています。
表 5–1 インタフェースの互換性の例|
オブジェクトの変更 |
更新タイプ |
|---|---|
|
シンボルの追加 |
互換性あり |
|
シンボルの削除 |
互換性なし |
|
非 varargs(3HEAD) 関数への引数の追加 |
互換性なし |
|
関数からの引数の削除 |
互換性なし |
|
関数への、または外部定義としてのデータ項目のサイズまたは内容の変更 |
互換性なし |
|
バグ修正または関数の内部拡張 (オブジェクトの意味プロパティを変更しない場合) |
互換性あり |
|
バグ修正または関数の内部拡張 (オブジェクトの意味プロパティを変更する場合) |
互換性なし |
シンボルを追加すると、割り込みが原因で、新しいシンボルがアプリケーションによるそのシンボルの使用法と矛盾するなど、互換性のない変更が生じる可能性があります。ただし、通常ソースレベル名前空間の管理が使用されるため、実際にはこの可能性はめったにありません。
互換性のある更新は、バージョン定義を生成されたオブジェクトの内部に維持することにより調整できます。互換性のない変更は、新しい外部バージョン管理名によって新しいオブジェクトを作成することにより調整できます。これらのバージョン管理手法を使用すると、アプリケーションの選択的割り当てを行うことができます。バージョン管理手法を使用すれば、実行時の正しいバージョン割り当てを検査することもできます。これらの 2 つの手法については、次の節でさらに詳しく説明します。
内部バージョン管理
動的オブジェクトには、1 つまたは複数の内部バージョン定義を関連付けることができます。各バージョン定義は通常、1 つまたは複数の名前に関連付けられます。シンボル名は、「1 つ」のバージョン定義にしか関連付けられません。ただし、バージョン定義は他のバージョン定義からシンボルを継承できます。したがって、1 つまたは複数の独立した、または関連するバージョン定義を作成中のオブジェクト内に定義するための構造が存在します。オブジェクトに新しい変更が加えられたら、新しいバージョン定義を追加してこれらの変更を表現することができます。
共有オブジェクト内にバージョン定義を与えた場合、次の 2 つの結果が得られます。
-
バージョン定義を与えられた共有オブジェクトに対して構築された動的オブジェクトは、それらが結合されているバージョン定義への依存関係を記録できる。これらのバージョンの依存関係は、アプリケーションの正しい実行に適切なインタフェースまたは機能を使用できるかどうかを確認するため、実行時に検査される
-
動的オブジェクトは、結合する共有オブジェクトのバージョン定義をリンク編集中に選択できる。このメカニズムを使用すると、開発者は、共有オブジェクト内の最も適したインタフェースまたは機能への、依存関係を制御することができる
バージョン定義の作成
バージョン定義は、一般にシンボル名と一意のバージョン名との関連付けからなります。これらの関連付けは、mapfile 内に確立され、リンカーの -M オプションを使用して、オブジェクトの最終リンク編集に与えられます。この手法については、シンボル範囲の縮小を参照してください。
バージョン定義は、バージョン名が mapfile 命令の一部として指定されている場合は必ず確立されます。次の例では、2 つのソースファイルが mapfile 命令とともに結合されて、定義済み公開インタフェースを持つオブジェクトを作成しています。
$ cat foo.c
extern const char * _foo1;
void foo1()
{
(void) printf(_foo1);
}
$ cat data.c
const char * _foo1 = "string used by foo1()\n";
$ cat mapfile
SUNW_1.1 { # Release X
global:
foo1;
local:
*;
};
$ cc -o libfoo.so.1 -M mapfile -G foo.o data.o
$ nm -x libfoo.so.1 | grep "foo.$"
[33] |0x0001058c|0x00000004|OBJT |LOCL |0x0 |17 |_foo1
[35] |0x00000454|0x00000034|FUNC |GLOB |0x0 |9 |foo1
|
シンボル foo1 は、共有オブジェクトの公開インタフェースを提供するために定義された唯一の大域シンボルです。特殊な自動縮小命令「*」は、他の大域シンボルすべてを縮小することによって、生成中のオブジェクト内にローカル結合が生じるようにします。この命令については、追加シンボルの定義を参照してください。関連バージョン名 SUNW_1.1 は、バージョン定義を生成させます。したがって、共有オブジェクトの公開インタフェースは、大域シンボル foo1 に関連付けられた内部バージョン定義 SUNW_1.1 からなります。
バージョン定義または自動縮小命令によってオブジェクトが生成されると、基本バージョン定義も必ず作成されます。この基本バージョンは、ファイル自体の名前を使用して定義され、リンカーによって生成された予約シンボルすべてを関連付けるために使用されます。予約シンボルのリストについては、出力ファイルの生成を参照してください。
オブジェクト内に含まれるバージョン定義は、pvs(1) に -d オプションを付けて使用して表示できます。
$ pvs -d libfoo.so.1
libfoo.so.1;
SUNW_1.1;
|
オブジェクト libfoo.so.1 には、基本バージョン定義 libfoo.so.1 とともに、SUNW_1.1 という名前の内部バージョン定義があります。
注 –
リンカーの -z noversion オプションを使用すると、mapfile 指示のシンボル縮小を実行できますが、バージョン定義の作成は抑制されます。
この初期バージョン定義から始めて、新しいインタフェースと更新された機能を追加することによって、オブジェクトを展開させることができます。たとえば、新機能 foo2 は、それがサポートするデータ構造とともに、ソースファイル foo.c および data.c を更新することによってオブジェクトに追加することができます。
$ cat foo.c
extern const char * _foo1;
extern const char * _foo2;
void foo1()
{
(void) printf(_foo1);
}
void foo2()
{
(void) printf(_foo2);
}
$ cat data.c
const char * _foo1 = "string used by foo1()\n";
const char * _foo2 = "string used by foo2()\n";
|
新しいバージョン定義 SUNW_1.2 を作成すると、シンボル foo2 を表わす新しいインタフェースを定義できます。また、この新しいインタフェースは、元のバージョン定義 SUNW_1.1 を継承するように定義できます。
この新しいインタフェースを作成すると、オブジェクトの展開が識別され、ユーザーは結合先のインタフェースを検査して選択できるため重要です。これらの概念については、バージョン定義への結合とバージョン結合の指定で詳しく説明します。
次の例は、これらの 1 つのインタフェースを作成する mapfile 命令を示しています。
$ cat mapfile
SUNW_1.1 { # Release X
global:
foo1;
local:
*;
};
SUNW_1.2 { # Release X+1
global:
foo2;
} SUNW_1.1;
$ cc -o libfoo.so.1 -M mapfile -G foo.o data.o
$ nm -x libfoo.so.1 | grep "foo.$"
[33] |0x00010644|0x00000004|OBJT |LOCL |0x0 |17 |_foo1
[34] |0x00010648|0x00000004|OBJT |LOCL |0x0 |17 |_foo2
[36] |0x000004bc|0x00000034|FUNC |GLOB |0x0 |9 |foo1
[37] |0x000004f0|0x00000034|FUNC |GLOB |0x0 |9 |foo2
|
foo1 と foo2 は、いずれも共有オブジェクトの公開インタフェースの一部として定義されています。ただし、これらの各シンボルは、別々のバージョン定義に割り当てられています。foo1 は SUNW_1.1 に、foo2 は SUNW_1.2 に割り当てられています。
これらのバージョン定義、その継承、およびそのシンボル関連付けは、pvs(1) に -d、-v、および -s オプションをつけて表示できます。
$ pvs -dsv libfoo.so.1
libfoo.so.1:
_end;
_GLOBAL_OFFSET_TABLE_;
_DYNAMIC;
_edata;
_PROCEDURE_LINKAGE_TABLE_;
_etext;
SUNW_1.1:
foo1;
SUNW_1.1;
SUNW_1.2: {SUNW_1.1}:
foo2;
SUNW_1.2
|
バージョン定義 SUNW_1.2 は、バージョン定義 SUNW_1.1 に対する依存関係を持っています。
あるバージョン定義から別のバージョン定義への継承は、バージョン依存関係に結合するオブジェクトによって最終的に記録されるバージョン情報を減らすために便利な手法です。バージョン継承については、バージョン定義への結合で詳しく説明します。
どの内部バージョン定義にも、対応するバージョン定義シンボルが作成されています。pvs(1) の例で示したように、これらのシンボルは -v オプションを使用して表示されます。
ウィークバージョン定義の作成
オブジェクトに対する新しいインタフェース定義の照会を必要としない内部変更は、ウィークバージョン定義を作成することによって定義できます。このような変更の例としては、バグ修正や性能の改善があります。
こういったバージョン定義は、大域インタフェースシンボルが関連付けられていないという点で空です。
たとえば、以前の例で使用したデータファイル data.c が、次のようにより詳しい文字列定義を提供するように更新されたとします。
$ cat data.c const char * _foo1 = "string used by function foo1()\n"; const char * _foo2 = "string used by function foo2()\n"; |
ウィークバージョン定義を照会すると、この変更を次のように識別できます。
$ cat mapfile
SUNW_1.1 { # Release X
global:
foo1;
local:
*;
};
SUNW_1.2 { # Release X+1
global:
foo2;
} SUNW_1.1;
SUNW_1.2.1 { } SUNW_1.2; # Release X+2
$ cc -o libfoo.so.1 -M mapfile -G foo.o data.o
$ pvs -dv libfoo.so.1
libfoo.so.1;
SUNW_1.1;
SUNW_1.2: {SUNW_1.1};
SUNW_1.2.1 [WEAK]: {SUNW_1.2};
|
空のバージョン定義は、ウィークラベルによって示されます。これらのウィークバージョン定義を使用すると、アプリケーションは、その機能に関連するバージョン定義に結合することによって、特定の実装状態の存在を検査できます。バージョン定義への結合では、これらの定義を使用する方法について詳しく説明します。
関連のないインタフェースの定義
以前の例は、オブジェクトに追加された新しいバージョン定義は、既存のバージョン定義をどのように継承するかを示しています。一意の依存しないバージョン定義を作成することもできます。次の例では、2 つの新しいファイル bar1.c と bar2.c がオブジェクト libfoo.so.1 に追加されています。これらのファイルは、2 つの新しいシンボル bar1 と bar2 をそれぞれ提供します。
$ cat bar1.c
extern void foo1();
void bar1()
{
foo1();
}
$ cat bar2.c
extern void foo2();
void bar2()
{
foo2();
}
|
これらの 2 つのシンボルは、2 つの新しい公開インタフェースの定義を目的としています。新しいインタフェースはどちらも相互に関連がありません。ただし、それぞれ元の SUNW_1.2 インタフェースへの依存関係を表しています。
次の mapfile 定義は、必要な関連付けを作成します。
$ cat mapfile
SUNW_1.1 { # Release X
global:
foo1;
local:
*;
};
SUNW_1.2 { # Release X+1
global:
foo2;
} SUNW_1.1;
SUNW_1.2.1 { } SUNW_1.2; # Release X+2
SUNW_1.3a { # Release X+3
global:
bar1;
} SUNW_1.2;
SUNW_1.3b { # Release X+3
global:
bar2;
} SUNW_1.2;
|
ここでも、この mapfile を使用して libfoo.so.1 に作成されたバージョン定義とそれらに関連する依存関係は、pvs(1) を使用して検査できます。
$ cc -o libfoo.so.1 -M mapfile -G foo.o bar1.o bar2.o data.o
$ pvs -dv libfoo.so.1
libfoo.so.1;
SUNW_1.1;
SUNW_1.2: {SUNW_1.1};
SUNW_1.2.1 [WEAK]: {SUNW_1.2};
SUNW_1.3a: {SUNW_1.2};
SUNW_1.3b: {SUNW_1.2};
|
次の節では、これらのバージョン定義記録を使用して、実行時結合の条件を検査し、オブジェクトの作成中にその結合を制御する方法について説明します。
バージョン定義への結合
動的実行可能ファイルまたは共有オブジェクトが、他の共有オブジェクトに対して構築される場合、これらの依存関係は結果オブジェクトに記録されます。詳細は、共有オブジェクトの処理 と 共有オブジェクト名の記録を参照してください。これらの共有オブジェクトの依存関係にバージョン定義も含まれる場合、関連のバージョン依存関係は構築されたオブジェクトに記録されます。
次の例は、前述のデータファイルを取り上げて、コンパイル時環境に適した共有オブジェクトを生成しています。この共有オブジェクト libfoo.so.1 は、次の結合例で使用されます。
$ cc -o libfoo.so.1 -h libfoo.so.1 -M mapfile -G foo.o bar.o \
data.o
$ ln -s libfoo.so.1 libfoo.so
$ pvs -dsv libfoo.so.1
libfoo.so.1:
_end;
_GLOBAL_OFFSET_TABLE_;
_DYNAMIC;
_edata;
_PROCEDURE_LINKAGE_TABLE_;
_etext;
SUNW_1.1:
foo1;
SUNW_1.1;
SUNW_1.2: {SUNW_1.1}:
foo2;
SUNW_1.2;
SUNW_1.2.1 [WEAK]: {SUNW_1.2}:
SUNW_1.2.1;
SUNW_1.3a: {SUNW_1.2}:
bar1;
SUNW_1.3a;
SUNW_1.3b: {SUNW_1.2}:
bar2;
SUNW_1.3b
|
実際には、この共有オブジェクトによって提供される 6 つの公開インタフェースがあります。これらのインタフェースのうち 4 つ (SUNW_1.1、SUNW_1.2、SUNW_1.3a、 SUNW_1.3b) はエクスポートされたシンボル名を定義します。1 つのインタフェース (SUNW_1.2.1) は共有オブジェクトに対する内部実装の変更を記述し、もう 1 つのインタフェース (libfoo.so.1 ) はいくつかの予約ラベルを定義します。この共有オブジェクトによって依存関係として作成される動的オブジェクトは、その動的オブジェクトが結合するインタフェースのバージョン名を記録します。
次の例では、シンボル foo1 と foo2 を参照するアプリケーションを作成しています。アプリケーションに記録されるバージョン管理依存関係に関する情報は、pvs(1) に -r オプションを付けて使用して調べることができます。
$ cat prog.c
extern void foo1();
extern void foo2();
main()
{
foo1();
foo2();
}
$ cc -o prog prog.c -L. -R. -lfoo
$ pvs -r prog
libfoo.so.1 (SUNW_1.2, SUNW_1.2.1);
|
この例では、アプリケーション prog は、実際に 2 つのインタフェース SUNW_1.1 と SUNW_1.2 に結合されています。これらのインタフェースは、それぞれ大域シンボル foo1 と foo2 を提供しました。
バージョン定義 SUNW_1.1 はバージョン定義 SUNW_1.2 から継承されたものとして libfoo.so.1 内に定義されているため、後者のバージョン依存関係も記録する必要があります。バージョン定義依存関係のこの正規化によって、オブジェクト内に保持されているバージョン情報の量は削減され、実行時に必要な処理が縮小されます。
アプリケーション prog は、ウィークバージョン定義 SUNW_1.2.1 を含む共有オブジェクトの実装状態に対して構築されるため、この依存関係も記録されます。このバージョン定義は、バージョン定義 SUNW_1.2 を継承するように定義されていますが、バージョンのウィーク性は SUNW_1.1 によるその正規化を阻害するため、依存関係は別々に記録されます。
相互に継承される複数のウィークバージョン定義がある場合、これらの定義は、ウィークでないバージョン定義と同じ方法で正規化されます。
注 –
バージョン依存関係の記録は、リンカーの -z noversion オプションによって抑制できます。
これらのバージョン定義依存関係の記録を終えると、実行時リンカーは、アプリケーションの実行時に結合されたオブジェクト内に必要なバージョン定義があるかどうかを検査します。この検査は、ldd(1) に -v オプションを付けて使用して表示できます。たとえば、アプリケーション prog に対して、ldd(1) を実行すると、バージョン定義依存関係は、共有オブジェクト libfoo.so.1 で正しく検出されることがわかります。
$ ldd -v prog
find object=libfoo.so.1; required by prog
libfoo.so.1 => ./libfoo.so.1
find version=libfoo.so.1;
libfoo.so.1 (SUNW_1.2) => ./libfoo.so.1
libfoo.so.1 (SUNW_1.2.1) => ./libfoo.so.1
....
|
注 –
ldd(1) に -v オプションを付けると、詳細出力が暗黙のうちに指定されます。 この出力では、すべての依存関係の再帰的なリストが、すべてのバージョン管理条件とともに生成されます。
ウィークでないバージョン定義依存関係を検出できないと、アプリケーションの初期設定中に重大なエラーが起こります。検出できないウィークバージョン定義依存関係は、暗黙の内に無視されます。たとえば、libfoo.so.1 がバージョン定義 SUNW_1.1 だけを含む環境で、アプリケーション prog が実行された場合は、次の重大なエラーが生じます。
$ pvs -dv libfoo.so.1
libfoo.so.1;
SUNW_1.1;
$ prog
ld.so.1: prog: fatal: libfoo.so.1: version `SUNW_1.2' not \
found (required by file prog)
|
アプリケーション prog がバージョン定義依存関係を記録しなかった場合は、必要なインタフェースシンボル foo2 が存在しないこと自体が、アプリケーションの実行中に重大な再配置エラーとして現われます。この再配置エラーは、プロセス初期設定中またはプロセス実行中に生じる可能性があります。また、アプリケーションの実行パスが関数 foo2 を呼び出さなかった場合には、まったく生じないこともあります。再配置エラーを参照してください。
バージョン定義依存関係を記録すると、アプリケーションによって必要なインタフェースが使用可能かどうかがすぐに示されます。
libfoo.so.1 がバージョン定義 SUNW_1.1 と SUNW_1.2 だけを含む環境内でアプリケーション prog が実行された場合、ウィークでないバージョン定義条件はすべて満たされます。ウィークバージョン定義 SUNW_1.2.1 の不在は重大ではないエラーと見なされるため、実行時エラー条件は生成されません。ただし、ldd(1) を使用すると、検出できないすべてのバージョン定義が表示されます。
$ pvs -dv libfoo.so.1
libfoo.so.1;
SUNW_1.1;
SUNW_1.2: {SUNW_1.1};
$ prog
string used by foo1()
string used by foo2()
$ ldd prog
libfoo.so.1 => ./libfoo.so.1
libfoo.so.1 (SUNW_1.2.1) => (version not found)
...........
|
注 –
オブジェクトが指定の依存関係からのバージョン定義を必要としている場合、実行時にその依存関係の実装状態にバージョン定義情報が含まれていないことがわかると、依存関係のバージョン検査は暗黙の内に無視されます。この方針は、非バージョン管理共有オブジェクトからバージョン管理共有オブジェクトへの移行が行われるときに、下位互換性レベルを提供するものです。ただし、ldd(1) は、バージョン条件の違いを表示するために引き続き使用できます。環境変数 LD_NOVERSION を使用すると、すべての実行時バージョン検査を抑制できます。
追加オブジェクトのバージョンの検査
バージョン定義シンボルも、dlopen(3DL) によって取得されたオブジェクトのバージョン条件を検査するメカニズムとなるものです。この関数を使用してプロセスのアドレス空間に追加されたオブジェクトに対しては、実行時リンカーによる自動バージョン依存関係検査が行われません。このため、この関数の呼び出し元が、バージョン管理条件が適合しているかどうかを検査する必要があります。
必要なバージョン定義があるかどうかは、dlsym(3DL) を使用して、関連のバージョン定義シンボルを調べることによって検査できます。次の例では dlopen(3DL) を使用して共有オブジェクト libfoo.so.1 をプロセスに追加し、インタフェース SUNW_1.2 が利用可能であることを確認します。
#include <stdio.h>
#include <dlfcn.h>
main()
{
void * handle;
const char * file = "libfoo.so.1";
const char * vers = "SUNW_1.2";
....
if ((handle = dlopen(file, (RTLD_LAZY | RTLD_FIRST))) == NULL) {
(void) printf("dlopen: %s\n", dlerror());
exit (1);
}
if (dlsym(handle, vers) == NULL) {
(void) printf("fatal: %s: version `%s' not found\n",
file, vers);
exit (1);
}
....
|
バージョン結合の指定
バージョン定義を含む共有オブジェクトに対して動的オブジェクトを作成する場合、リンカーに対して、特定のバージョン定義への結合を制限するように指示することができます。リンカーを使用すると、特定インタフェースへのオブジェクトの結合を効果的に制御することができます。
オブジェクトの結合条件は、ファイル制御命令によって制御できます。この命令は、リンカーの -M オプションと関連の mapfile を使用して提供されます。ファイル制御命令には、次の構文を使用します。
name - version [ version ... ] [ $ADDVERS=version ]; |
-
name — 共有オブジェクト依存関係の名前を表す。この名前は、リンカーによって使用される共有オブジェクトのコンパイル環境名と一致しなければなりません。ライブラリの命名規約を参照してください。
-
version – 結合に使用可能でなければならない共有オブジェクト内のバージョン定義名を表わす。複数のバージョン定義を指定できる。
この結合制御は、次のような場合に役立ちます。
-
共有オブジェクトが一意の独立したバージョンを定義するとき。このバージョン管理は、異なる標準インタフェースを定義するときに使用できる。結合制御でオブジェクトを構築することによって、そのオブジェクトが特定のインタフェースだけに結合することを保証できる。
-
複数世代のソフトウェアリリースにまたがって、共有オブジェクトをバージョン管理するとき。結合制御でオブジェクトを構築することによって、以前のソフトウェアリリースで利用可能なインタフェースだけに結合するように制限できる。したがって、最新リリースの共有オブジェクトを使用して構築したオブジェクトでも、古いリリースの共有オブジェクトを使用して実行できる。
次に、バージョン制御機構の使用例を示します。この例では、次のバージョンインタフェース定義を含む共有オブジェクト libfoo.so.1 を使用しています。
$ pvs -dsv libfoo.so.1
libfoo.so.1:
_end;
_GLOBAL_OFFSET_TABLE_;
_DYNAMIC;
_edata;
_PROCEDURE_LINKAGE_TABLE_;
_etext;
SUNW_1.1:
foo1;
foo2;
SUNW_1.1;
SUNW_1.2: {SUNW_1.1}:
bar;
|
バージョン定義 SUNW_1.1 および SUNW_1.2 は、ソフトウェア Release X および Release X+1 で使用可能な libfoo.so.1 内のインタフェースをそれぞれ表わします。
アプリケーションは、次のバージョン制御 mapfile 命令を使用して、Release X で使用可能なインタフェースだけに結合するように構築できます。
$ cat mapfile libfoo.so - SUNW_1.1; |
たとえば、Release X 上で動作するアプリケーション prog を 開発するとします。その場合、アプリケーションでは、そのリリースで使用可能なインタフェース以外は使用できません。シンボル bar を間違えて参照すると、アプリケーションは要求されるインタフェースに準拠しなくなります。リンカーはこの状態を未定義のシンボルエラーとして通知します。
$ cat prog.c
extern void foo1();
extern void bar();
main()
{
foo1();
bar();
}
$ cc -o prog prog.c -M mapfile -L. -R. -lfoo
Undefined first referenced
symbol in file
bar prog.o (symbol belongs to unavailable \
version ./libfoo.so (SUNW_1.2))
ld: fatal: Symbol referencing errors. No output written to prog
|
SUNW_1.1 インタフェースに準拠するには、bar への参照を削除する必要があります。これは、アプリケーションを再処理して bar に対する条件を削除するか、または bar の実装をアプリケーションの作成に追加することによって行います。
注 –
デフォルトでは、リンク編集の一部として遭遇した共有オブジェクト依存関係もファイル制御命令に対して確認されます。環境変数 LD_NOVERSION を使用して、共有オブジェクト依存関係のバージョン検査を抑制します。
追加バージョン定義への結合
通常のオブジェクトシンボル結合から作成されるバージョン依存関係に、追加のバージョン依存関係を記録するには、$ADDVERS ファイル制御命令を使用します。この節では、この追加結合が役に立ついくつかのシナリオについて説明します。
libfoo.so.1 の例に続いて、Release X+2 において、バージョン定義 SUNW_1.1 が 2 つの標準リリース STAND_A と STAND_B に分割される場合を想定します。互換性を維持するには、SUNW_1.1 バージョン定義を維持する必要があります。次の例では、このバージョン定義は 2 つの標準定義を継承するものとして表わされています。
$ pvs -dsv libfoo.so.1
libfoo.so.1:
_end;
_GLOBAL_OFFSET_TABLE_;
_DYNAMIC;
_edata;
_PROCEDURE_LINKAGE_TABLE_;
_etext;
SUNW_1.1: {STAND_A, STAND_B}:
SUNW_1.1;
SUNW_1.2: {SUNW_1.1}:
bar;
STAND_A:
foo1;
STAND_A;
STAND_B:
foo2;
STAND_B;
|
アプリケーション prog の唯一の条件がインタフェースシンボル foo1 である場合、このアプリケーションはバージョン定義 STAND_A に対して単一の依存関係を持ちます。このことは、libfoo.so.1 が Release X+2 よりも小さいシステムでの prog の実行を阻害します。以前のリリースでは、インタフェース foo1 が存在する場合でも、バージョン定義 STAND_A は存在しませんでした。
アプリケーション prog は、SUNW_1.1 に対する依存関係を作成することによって、その条件を以前のリリースに合わせて構築できます。
$ cat mapfile
libfoo.so - SUNW_1.1 $ADDVERS=SUNW_1.1;
$ cat prog
extern void foo1();
main()
{
foo1();
}
$ cc -M mapfile -o prog prog.c -L. -R. -lfoo
$ pvs -r prog
libfoo.so.1 (SUNW_1.1);
|
この明示的な依存関係は、真の依存関係の条件をカプセル化するのに十分です。この依存関係は古いリリースとの互換性も保ちます。
ウィークバージョン定義の作成では、ウィークバージョン定義を使用して、内部実装の変更をマークする方法について説明しました。これらのバージョン定義は、オブジェクトに対して行われたバグ修正と性能の改善に適しています。ウィークバージョンの存在が必要である場合、ウィークバージョン定義への明示的な依存関係を作成できます。オブジェクトを正しく機能させるためにバグ修正や性能の改善が重要な場合、このような依存関係の作成も重要になります。
上記の libfoo.so.1 の例で、バグ修正がウィークバージョン定義 SUNW_1.2.1 としてソフトウェア Release X+3 に組み込まれている場合を想定します。
$ pvs -dsv libfoo.so.1
libfoo.so.1:
_end;
_GLOBAL_OFFSET_TABLE_;
_DYNAMIC;
_edata;
_PROCEDURE_LINKAGE_TABLE_;
_etext;
SUNW_1.1: {STAND_A, STAND_B}:
SUNW_1.1;
SUNW_1.2: {SUNW_1.1}:
bar;
STAND_A:
foo1;
STAND_A;
STAND_B:
foo2;
STAND_B;
SUNW_1.2.1 [WEAK]: {SUNW_1.2}:
SUNW_1.2.1;
|
通常、アプリケーションは、この共有オブジェクトに対して構築されている場合、バージョン定義 SUNW_1.2.1 に対する弱い依存関係を記録します。この依存関係は情報提供だけを目的とします。実行時に使用される libfoo.so.1 にバージョン定義が見つからなくても、この依存関係によってアプリケーションが強制終了されることはありません。
ファイル制御命令 $ADDVERS を使用すると、バージョン定義に対する明示的な依存関係を生成できます。この定義がウィークである場合、この明示的参照によって、バージョン定義が強い依存関係に高められます。
アプリケーション prog は、次のファイル制御命令を使用して、SUNW_1.2.1 インタフェースを実行時に使用できるという条件を実施するように構築できます。
$ cat mapfile
libfoo.so - SUNW_1.1 $ADDVERS=SUNW_1.2.1;
$ cat prog
extern void foo1();
main()
{
foo1();
}
$ cc -M mapfile -o prog prog.c -L. -R. -lfoo
$ pvs -r prog
libfoo.so.1 (SUNW_1.2.1);
|
prog は、インタフェース STAND_A に対する明示的な依存関係によって構築されています。バージョン定義 SUNW_1.2.1 は、強いバージョンに高められているため、依存関係 STAND_A によっても正規化されます。実行時にバージョン定義 SUNW_1.2.1 が見つからないと、重大なエラーが生成されます。
注 –
依存関係が少ない場合、リンカーの -u オプションを使用して、バージョン定義に明示的に結合できます。このオプションで、バージョン定義シンボルを参照します。ただし、シンボル参照は非選択的です。類似の名前を持つ複数のバージョン定義を含む可能性がある複数の依存関係を処理する場合は、この手法で明示的な結合を作成できないことがあります。
バージョンの安定性
個々のバージョンの定義がそのオブジェクトの使用期間にわたって変更されなければ、1 つのオブジェクト内の複数のバージョンに結合する各種のモデルは損なわれません。
一度オブジェクトに対してバージョン定義を作成して公開したら、そのバージョン定義は、そのオブジェクトの次のリリースでも変更されずに存在していなければなりません。バージョン名およびそれに関連するシンボルは両方とも変更しないでください。このため、バージョン定義内で定義されるシンボル名には、ワイルドカードによる拡張はサポートされていません。これは、ワイルドカードに当てはまるシンボルの数が、オブジェクトが発展する過程で異なる場合があるからです。
再配置可能オブジェクト
バージョン情報は、動的オブジェクト内で記録して使用できます。再配置可能オブジェクトは、同様の方法でバージョン管理情報を保持できます。ただし、これらの情報の使用方法に多少違いがあります。
再配置可能オブジェクトのリンク編集に提供されるバージョン定義はすべて、動的実行可能ファイルや共有オブジェクトを構築するときとまったく同じ形式で記録されます。ただしデフォルトにより、作成中のオブジェクトに対するシンボル削減は実行されません。代わりに、再配置可能オブジェクトが動的オブジェクトの生成に対して最終的に入力として使用されると、バージョン記録自体が、適用するシンボル削減を判定するために使用されます。
また、再配置可能オブジェクトで検出されたバージョン定義はすべて、動的オブジェクトに伝達されます。再配置可能オブジェクトでのバージョン処理の例については、シンボル範囲の縮小を参照してください。
外部バージョン管理
共有オブジェクトへの実行時参照は、常にファイルのバージョンファイル名を参照しなければなりません。通常、これはバージョン番号が接尾辞として付いたファイル名として表わされます。共有オブジェクトのインタフェースが互換性のない方法で (古いアプリケーションを破壊するような方法で) 変更される場合は、新しい共有オブジェクトを新しいバージョン管理ファイル名によって配布する必要があります。また、元のバージョン管理ファイル名も配布して、古いアプリケーションで必要なインタフェースを提供する必要があります。
一連のソフトウェアリリースに対してアプリケーションを構築しているときは、実行時環境内に共有オブジェクトを個別のバージョンファイル名で提供する必要があります。このようにすれば、アプリケーションを構築するときに基にしたインタフェースを使用して、実行中に結合することができます。
次の節では、コンパイル環境と実行時環境間でのインタフェースの結合を同期する方法について説明します。
バージョン管理ファイル名の管理
リンク編集中に共有オブジェクトを入力するための最も一般的な手法は、-l オプションを使用する方法です。このオプションは、リンカーのライブラリ検索機構を使用して接頭辞 lib と接尾辞 .so が付いた共有オブジェクトを探します。
ただし、実行時に、共有オブジェクト依存関係は、そのバージョン管理ファイル名形式で存在していなければなりません。これらの命名規約に従う 2 つの異なる共有オブジェクトを維持するのではなく、2 つのファイル名間にファイルシステムリンクを作成します。
実行時共有オブジェクト libfoo.so.1 をコンパイル環境で使用できるようにするには、コンパイルファイル名から実行時ファイル名にシンボリックリンクを与えます。次に例を示します。
$ cc -o libfoo.so.1 -G -K pic foo.c $ ln -s libfoo.so.1 libfoo.so $ ls -l libfoo* lrwxrwxrwx 1 usr grp 11 1991 libfoo.so -> libfoo.so.1 -rwxrwxr-x 1 usr grp 3136 1991 libfoo.so.1 |
シンボリックリンクまたはハードリンクを使用できます。ただし記述および診断目的としては、シンボリックリンクの方が有効です。
共有オブジェクト libfoo.so.1 は、実行時環境用に生成されています。シンボリックリンク libfoo.so の生成は、コンパイル環境でのこのファイルの使用も有効にしています。次に例を示します。
$ cc -o prog main.o -L. -lfoo |
リンカーは、シンボリックリンク libfoo.so を追って見つける共有オブジェクト libfoo.so.1 によって記述されたインタフェースを使用して、再配置可能オブジェクト main.o を処理します。
一連のソフトウェアリリースにわたって、この共有オブジェクトの新しいバージョンごとにインタフェースを変更して配布できます。シンボリックリンクを変更することによって、適用可能なインタフェースを使用するよう、コンパイル環境を構築することができます。次に例を示します。
$ ls -l libfoo* lrwxrwxrwx 1 usr grp 11 1993 libfoo.so -> libfoo.so.3 -rwxrwxr-x 1 usr grp 3136 1991 libfoo.so.1 -rwxrwxr-x 1 usr grp 3237 1992 libfoo.so.2 -rwxrwxr-x 1 usr grp 3554 1993 libfoo.so.3 |
共有オブジェクトの 3 つの主要バージョンが使用できます。これらの共有オブジェクトのうち、libfoo.so.1 と libfoo.so.2 の 2 つは、既存アプリケーションに対する依存関係を提供します。libfoo.so.3 は、新しいアプリケーションを作成して実行するための最新主要リリースを提供します。
このシンボリックリンク機構自体を使用するだけでは、コンパイル環境での使用から実行時環境での条件に合わせて共有オブジェクトを正しく結合することはできません。例が示しているように、リンカーは、動的実行可能ファイル prog に、それが処理した共有オブジェクトのファイル名を記録します。この場合、そのファイル名はコンパイル環境のファイル名です。
$ dump -Lv prog prog: **** DYNAMIC SECTION INFORMATION **** .dynamic: [INDEX] Tag Value [1] NEEDED libfoo.so ......... |
アプリケーション prog が実行されると、実行時リンカーは、依存関係 libfoo.so を検索します。prog は、このシンボリックリンクが指すすべてのファイルに結合されます。
依存関係として記録される正しい実行時名を指定するには、共有オブジェクト libfoo.so.1 を「soname」定義によって構築する必要があります。この定義は、共有オブジェクトの実行時名を識別します。この名前は、この共有オブジェクトに対してリンクするすべてのオブジェクトによって、依存関係名として使用されます。この定義は、共有オブジェクト自体のリンク編集中に -h オプションを使用して与えることができます。次に例を示します。
$ cc -o libfoo.so.1 -G -K pic -h libfoo.so.1 foo.c $ ln -s libfoo.so.1 libfoo.so $ cc -o prog main.o -L. -lfoo $ dump -Lv prog prog: **** DYNAMIC SECTION INFORMATION **** .dynamic: [INDEX] Tag Value [1] NEEDED libfoo.so.1 ......... |
このシンボリックリンクと「soname」機構は、コンパイル環境と実行時環境の共有オブジェクト命名規約の間に強固な同期を確立しました。 リンク編集中に処理されたインタフェースは、生成された出力ファイルに正確に記録されます。この記録によって、意図したインタフェースが実行時に提供されます。
注意 – 外部的にバージョン管理された新しい共有オブジェクトを作成することは、大きな変更です。この共有オブジェクトを使用するすべてのプロセスの依存関係を完全に理解している必要があります。
たとえば、あるアプリケーションが、libfoo.so.1 および外部から記述されたオブジェクト libISV.so.1 と依存関係があるとします。この後者のオブジェクトは libfoo.so.1 とも依存関係があるとします。外部オブジェクト libISV.so.1 の使用には何の変更も加えずに、libfoo.so.2 内の新しいインタフェースを使用するためにアプリケーションを再設計すると、libfoo.so の主要なバージョンが両方とも実行プロセスに含まれることになります。libfoo.so のバージョンを変更する理由は互換性のない変更をマークすることだけなので、プロセス内にオブジェクトの両方のバージョンを持つことは、不正なシンボル結合が発生する原因となり、そのために望ましくない相互作用を引き起こすことがあります。
- © 2010, Oracle Corporation and/or its affiliates