補助フィルタの生成

補助フィルタの作成方法は、標準フィルタの場合と基本的に同じです (詳細については、「標準フィルタの生成」を参照)。まず、このフィルタ手法を適用するフィルティー libbar.so.1 を定義します。このフィルティーは、いくつかの再配置可能オブジェクトから構築される場合があります。これらのオブジェクトの 1 つは、ファイル bar.c から発生し、シンボル foo を提供します。

$ cat bar.c
char * foo()
{
    return("defined in bar.c");
}
$ cc -o libbar.so.1 -G -K pic .... bar.c ....

補助フィルタ libfoo.so.1 が、シンボル foo と bar に対して生成されて、フィルティー libbar.so.1 への関連付けを示します。次に例を示します。

$ cat foo.c
char * bar = "foo";

char * foo()
{
    return ("defined in foo.c");
}
$ LD_OPTIONS='-f libbar.so.1' ¥
cc -o libfoo.so.1 -G -K pic -h libfoo.so.1 -R. foo.c
$ ln -s libfoo.so.1 libfoo.so
$ dump -Lv libfoo.so.1 | egrep "SONAME|AUXILIARY"
[1]     SONAME    libfoo.so.1
[2]     AUXILIARY libbar.so.1

ここで、環境変数 LD_OPTIONS は、このコンパイラドライバが -f オプションをそれ自体のオプションの 1 つとして解釈しないようにするために使用されています。

リンカーは、補助フィルタ libfoo.so.1 を参照して動的実行可能ファイルまたは共有オブジェクトを作成する場合、シンボル解決中、フィルタシンボルテーブルの情報を使用します (詳細については、「シンボル解析」を参照)。

実行時にフィルタのシンボルを参照すると、フィルティー libbar.so.1 が検索されます。このフィルティーが見つかると、実行時リンカーは、このフィルティーを使用して、libfoo.so.1 によって定義されたすべてのシンボルを解釈処理します。このフィルティーが見つからないか、またはフィルティーにフィルタからのシンボルがない場合は、フィルタ内のシンボルの元の値が使用されます。

たとえば、次の動的実行可能ファイル prog は、シンボル foo と bar を参照します。これらのシンボルは、フィルタ libfoo.so.1 からのリンク編集中に解釈処理されます。

$ cat main.c
extern char * bar, * foo();

main(){
    (void) printf("foo() is %s: bar=%s¥n", foo(), bar);
}
$ cc -o prog main.c -R. -L. -lfoo
$ prog
foo() is defined in bar.c: bar=foo

動的実行可能ファイル prog を実行すると、関数 foo() は、フィルタ libfoo.so.1 からではなく、フィルティー libbar.so.1 から取得されます。ただし、データ項目 bar は、フィルタ libfoo.so.1 から取得されます。このシンボルは、フィルティー libbar.so.1 に代替定義を持たないためです。

補助フィルタは、既存の共有オブジェクトの代替インタフェースを定義するメカニズムとなります。このメカニズムは Solaris で使用されて、プラットフォーム固有の共有オブジェクト内に最適化された機能を提供します。例は、「命令セット固有の共有オブジェクト」および 「プラットフォーム固有の共有オブジェクト」を参照してください。