補助フィルタの生成

補助フィルタの作成方法は、標準フィルタの場合と基本的に同じです (詳細については、標準フィルタの生成を参照)。まず、このフィルタ手法を適用するフィルティー 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 への関連付けを示します。環境変数 LD_OPTIONS は、このコンパイラドライバが -f オプションをそれ自体のオプションの 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

リンカーは、補助フィルタ 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 オペレーティング環境で使用されて、プラットフォーム固有の共有オブジェクト内に最適化された機能を提供します。例は、命令セット固有の共有オブジェクトおよび システム固有の共有オブジェクトを参照してください。

環境変数 LD_NOAUXFLTR を設定して、実行時リンカーの補助フィルタ処理を無効にすることができます。補助フィルタはプラットフォーム固有の最適化に使用されることが多いので、フィルティーを使用する場合および性能インパクトを評価する場合にこのオプションが便利です。