補助フィルタの作成方法は、標準フィルタの場合と基本的に同じです (詳細については、「標準フィルタの生成」を参照)。まず、このフィルタ手法を適用するフィルタ対象 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 で使用されて、プラットフォーム固有の共有オブジェクト内に最適化された機能を提供します。例は、「命令セット固有の共有オブジェクト」および 「プラットフォーム固有の共有オブジェクト」を参照してください。