C ユーザーズガイド ホーム目次前ページへ次ページへ索引

第 5 章

インクリメンタルリンカー (ild)

この章では、インクリメンタルリンカー (ild)、ild に固有の機能、メッセージ例、および ild オプションについて説明します。説明項目は次のとおりです。

インクリメンタルリンカーとは

ild はインクリメンタルリンカーといい、ld (通常のリンカー) の代わりにプログラムのリンク処理を行います。ild を使用すると、ld を使用するよりも、開発 (編集、コンパイル、リンク、デバッグの繰り返し) をより効率的に速く行うことができます。全体の再リンクを行わずに処理を続けるには dbx の「修正継続」機能も使用できますが、ild を使用すると処理がより速くなります。修正継続機能の詳細については『dbx コマンドによるデバッグ』の第 11 章を参照してください。

ild では変更部分だけがリンクされるので、変更していないオブジェクトファイルは再リンクを行わずに、変更したオブジェクトコードを以前に作成した実行可能ファイルに挿入することができます。再リンクに必要な時間は、変更したコードの量によって異なります。コードの変更が少ない場合は、リンク処理にかかる時間は短くなります。

初めてリンクを行う時には ild でも ld と同じくらいの時間が必要ですが、その後の ild リンクは ld リンクよりかなり時間が短縮されます。ただし、ild リンクの方が実行可能ファイルのサイズが大きくなります。

インクリメンタルリンク処理の概要

ild を使用すると、初期リンクで、さまざまなテキスト、データ、bss、例外テーブルセクションなどが後にプログラムを拡張するときのための予備スペース (パディング) とともにスペースが追加されます (図 5-1 を参照)。また、すべての再配置レコードと大域シンボルテーブルが、実行可能ファイルの新しい永久領域に保存されます。さらにインクリメンタルリンクを行うと、タイムスタンプによって、どのオブジェクトファイルが変更されたかが調べられ、変更されたオブジェクトコードが以前に作成した実行可能ファイルに追加されます。すなわち、以前のバージョンのオブジェクトファイルは無効になり、空き領域または必要に応じて実行可能ファイルのパディングセクションに、新しいオブジェクトファイルが読み込まれます。無効になったオブジェクトファイル内のシンボルに対する参照はすべて、修正された新しいオブジェクトファイルを参照するように変更されます。

すべての ld コマンドオプションが ild でサポートされているわけではありません。ild でサポートされていないコマンドオプション (「注意事項」を参照) を指定すると、/usr/ccs/bin/ld が起動されて、リンクが行われます。

ild の使用法

ild は特定の条件が揃った場合に、 ld の代わりにコンパイラによって自動的に呼び出されます。コンパイラを起動するとコンパイラドライバが起動され、ドライバは特定のオプションを渡された場合に ild を使用します。コンパイラドライバはコマンド行からオプションを読み取り、プログラムを正しい順序で実行し、渡された引数リストに従ってファイルを追加します。

たとえば、cc は最初に acomp (コンパイラのフロントエンド) を実行し、acomp が最適化コードジェネレータを実行します。続いて cc は、コマンド行に指定されている他のソースファイルに対しても同じ処理を行います。次に、指定されたオプションによって ild または ld のどちらかを呼び出し、コンパイルしたすべてのファイルと、プログラムを完成させるために必要な他のファイルやライブラリを、 ild または ld に渡します。

次の図に、インクリメンタルリンク処理の例を示します。

図 5-1   インクリメンタルリンク処理の例

ild と ld のどちらを使用するかは、コンパイラのオプションによって次のように制御されます。

デフォルトのメークファイル構造 (リンクコマンド行内に -g オプションのようなコンパイルオプションを含む) で -g オプションを指定してデバッグを行うと、自動的に ild が使用されます。

ild の動作

初期リンク時には以下の情報が保存されます。

ild の初期リンクでは、ld リンクとほぼ同じ時間がかかります。

インクリメンタルリンクでは以下の処理が行われます。

ild のインクリメンタルリンクは ld リンクより高速です。

通常は、一回だけ初期リンクを行い、その後のリンクはすべてインクリメンタルリンクを実行します。

たとえば、ild ではコード内でシンボル foo を参照しているすべての場所が保存されます。foo の値を変更するインクリメンタルリンクを行うと、foo を参照している値もすべて変更する必要が生じます。

そこで ild は、プログラムの構成要をいくつかに分散し、実行可能ファイルの各セクションにパディングを追加します。パディングによって、ld リンクを実行したときよりも、実行可能モジュールのサイズが大きくなります。インクリメンタルリンクを何度か繰り返すうちに、オブジェクトファイルのサイズは徐々に大きくなっていくので、パディングがすべて使用されてしまうことがあります。このような場合には、メッセージが表示され、実行可能ファイル全体に対して完全再リンクが行われます。

たとえば、図 5-1 の 3 つの図は、それぞれリンク済み実行可能ファイルのテキストとデータの並びを示しています。左の図は、ld がリンクした実行可能ファイルのテキストとデータを示します。中央の図は、ild がリンクした実行可能ファイルにテキストとデータのパディングが追加された様子を示します。ソースファイルのテキスト 1 に対して、テキスト 1 以外のセクションのサイズには影響を与えずに、テキスト 1 のサイズだけが増えるような変更が行われたとします。右の図では、テキスト 1 の元の位置がテキストパディングに置き換えられています (テキスト 1 は無効になります)。元のテキスト 1 はテキストパディング領域の一部分に移動されています。

-xildon オプションを指定せずにコンパイラドライバ (たとえば、cc または CC) を起動すると ld が呼び出されるので、インクリメンタルでないリンクが行われ、サイズがより小さな実行可能ファイルが作成されます。

dbx デバッガは、ild によってプログラムの間に挿入されたパディングを認識することができるので、ild で作成された実行可能ファイルのデバッグを行うことができます。

ild が認識できないコマンド行オプションを指定すると、ild は ld (/usr/ccs/bin/ld) を呼び出します。ild は ldと互換性があり、詳細は、「ild オプション」を参照してください。

ild でしか使用できないファイルはありません。

ild の制限事項

共有オブジェクトを作成する場合に ild を起動しても、ld が起動されてリンクが実行されます。

オブジェクトファイルに多くの変更を加えると、ild の処理速度が低下することがあります。ild は、ファイルに多くの変更が加えられていることを検出すると、自動的に完全再リンクを行います。

最終的に製品となるコードを作成するときには ild (-xildon オプション) を使用しないでください。ild を使用すると、パディングによってプログラムが分散されるため、作成されるファイルのサイズが大きくなり、リンクに余分な時間がかかります (-g オプションがある場合は -xildoff を使用してください)。

小さいプログラムでは ild を使用しても、リンク処理の時間はあまり短縮されません。また、大きなプログラムよりも、実行可能ファイルのサイズが増加する割合が高くなることがあります。

実行可能ファイルを操作する他社のツールを ild で作成したバイナリに使用すると、予想外の結果が出ることがあります。

実行可能ファイルを修正するプログラム (たとえば、strip または mcs など) を使用すると、ild のインクリメンタルリンク機能に影響を及ぼすことがあります。このような場合には、メッセージが表示されて完全再リンクが実行されます。詳細については、138 ページの「完全再リンクが行われる場合」を参照してください。

完全再リンクが行われる場合

以下に、リンクを実行するために ild が ld を呼び出す例を示します。

ild 先送りリンクメッセージ

メッセージ「ild: calling ld to finish link」は、ild がリンクを実行できないため ld に先送りしてリンクを実行することを意味します。このようなメッセージはデフォルトでは出力されますが、-z i_quiet オプションを使って出力されないようにすることもできます。

次のメッセージは ild が暗黙的に (-g オプションで) 要求されている場合は抑制できますが、コマンド行で -xildon が指定されている場合は常に表示されます。このメッセージは -z i_verbose オプションを指定すると常に表示され、-z i_quiet オプションを指定すると表示されません。

ild: calling ld to finish link -- cannot handle shared libraries in 
archive <ライブラリ名>


 

<訳>


 

ld によるリンクを実行します　--  アーカイブ <ライブラリ名> の共有ライブラリを処理できません



  














   以下に、-z i_verbose メッセージのその他の例を示します。



  
  

     

ild: calling ld to finish link -- cannot handle keyword <キーワード名>


 

ild: calling ld to finish link -- cannot handle -d <キーワード名>


 

ild: calling ld to finish link -- cannot handle -z <キーワード名>


 

ild: calling ld to finish link -- cannot handle argument <キーワード名>


 


 

<訳>


 

ld によるリンクを実行します　--  キーワード <キーワード名> を処理できません


 

ld によるリンクを実行します　--  -d <キーワード名> を処理できません


 

ld によるリンクを実行します　--  -z <キーワード名> を処理できません


 

ld によるリンクを実行します　--  引数 <キーワード名> を処理できません



  














   ild 再リンクメッセージ






   メッセージ「ild: (Performing full relink)」は、何らかの理由で ild がインクリメンタルリンクを実行できないため、完全再リンクを実行しなければならないことを示します。これはインクリメンタルリンクより時間がかかることを示すメッセージであり、エラーではありません (詳細は、136 ページの「ild の動作」を参照してください)。ild のメッセージは -z i_quiet オプションと -z i_verbose オプションで制御できます。一部のメッセージには詳細情報モードがあり、より詳しい情報が示されます。






   これらのメッセージはすべて -z i_quiet オプションで抑制できます。デフォルトメッセージが詳細情報モードの場合はメッセージの最後に [...] と表示され、詳細情報があることを示します。詳細情報は、-z i_verbose オプションを使用して参照できます。以下の例では、-z i_verbose オプションが選択されています。






   例 1: 内部空き領域の不足






   完全再リンクでよく表示されるメッセージとして、「internal free space exhausted」があります。



  
  

    
 

    



    
 

$ cat test1.c 



  

  

    
 

    



    
 

int main() { return 0; }



  

  

    
 

    



    
 

$ rm a.out



  

  

    

 # test1.o を作成



    
 

$ cc -xildon -c -g test1.c



  

  

    
 

# 最小限のデバッグ情報を


 

a.out に出力



    
 

$ cc -xildon -z i_verbose -g test1.o



  

  

    
 

# 1 行でコンパイルとリンクを


 

を行い、デバッグ情報をすべ


 

て a.out に出力



    
 

$ cc -xildon -z i_verbose -g test1.c



  

  

    
 

    



    
 

ild: (Performing full relink) internal free 
space in output file exhausted (sections)



  

  

    
 

    



    
 

$



  

  

    
 



    
 

<訳>


 

完全再リンクを実行します


 

-- 出力ファイルの容量が不足しています



  















   この例からわかるように、1 行コンパイルから 2 行コンパイルに変更すると、実行可能ファイル内のデバッグ情報が増え、このために領域が不足し、完全再リンクが実行されます。






   例 2: strip の実行






   strip を実行すると、別の問題が発生します。次の例は例 1 からの続きです。



  
  

    
 

# a.out を取り除く



    
 

$ strip a.out



  

  

    
 

# インクリメンタルリンクを行お
うとする



    
 

$ cc -xildon -z i_verbose -g test1.c



  

  

    
 

    



    
 

ild: (Performing full relink) a.out has been 
altered since the last incremental link -- 
maybe you ran strip or mcs on it?



  

  

    
 

    



    
 

$



  

  

    
 



    
 

<訳>


 

完全再リンクを実行します


 

--  最後のインクリメンタルリンク以降に strip または 
mcs を実行したために、a.out が変更されています。



  















   例 3: ild のバージョン






   旧バージョンの ild で作成した実行可能ファイルに対して、新バージョンの ild を実行すると、以下のようなエラーメッセージが表示されます。



  
  

    
 

# old_executableは ild の以前
のバージョンで作成



    
 

$ cc -xildon -z i_verbose foo.o -o old_executable



  

  

    
 

    



    
 

ild: (Performing full relink) an updated ild 
has been installed since a.out was last linked 
(2/16)



  

  

    
 



    
 

<訳>


 

完全再リンクを実行します　


 

--  最後の a.out のリンク以降に、更新された ild がイ
ンストールされています (2/16)



  















   注 - 数字 (2/16) は、バグレポート用に使用されます。






   例 4: 変更されたファイルが多い






   インクリメンタルリンクより完全再リンクを行う方が、処理時間が短くなる場合があります。以下に例を示します。



  
  

    
 

$ rm a.out



  

  

    
 

$ cc -xildon -z i_verbose \



  

  

    
 

     x0.o x1.o x2.o x3.o x4.o x5.o x6.o x7.o x8.o test2.o



  

  

    
 

$ touch x0.o x1.o x2.o x3.o x4.o x5.o x6.o x7.o x8.o



  

  

    
 

$ cc -xildon -z i_verbose \



  

  

    
 

     x0.o x1.o x2.o x3.o x4.o x5.o x6.o x7.o x8.o test2.o



  

  

    
 

ild: (Performing full relink) too many files changed



  

  

    
 

<訳>


 

完全再リンクを実行します　-- 変更されたファイルが多すぎます



  















   ファイル x0.o から x8.o が変更されているので、touch コマンドを使用すると、9 つのオブジェクトファイルをすべてインクリメンタルリンクするより、完全再リンクを行う方が処理時間が短縮されます。






   例 5: 新たな完全再リンク






   例 4 は、これから行うリンクで完全再リンクを実行する例でしたが、その次に行うリンクで初期リンクを実行してしまう不具合があります。






   次にこのプログラムをリンクしようとすると、以下のメッセージが表示されます。



  
  

     

# 以前のエラーを検出し完全
再リンクを行う



    
 

$ cc -xildon -z i_verbose  broken.o



  

  

    
 

ild: (Performing full relink) cannot do incremental 
relink due to problems in the previous link



  

  

    
 



    
 

<訳>


 

完全再リンクを実行します　


 

--  前回のリンクに問題があるため、インクリメンタルリンクを実行
できません



  















   新たに完全再リンクが行われます。






   例 6: 新たな作業用ディレクトリ



  
  

    
 

    



    
 

% cd /tmp



  

  

    
 

    



    
 

% cat y.c



  

  

    
 

    



    
 

    int main(){ return 0;}



  

  

    
 

    



    
 

% cc -c y.c



  

  

    
 

    



    
 

% rm -f a.out



  

  

    
 

# 現在の作業ディレクトリでの
初期リンク。/tmp で行う場合
と同じ。



    
 

% cc -xildon -z i_verbose y.o -o a.out



  

  

    
 

    



    
 

% mkdir junk



  

  

    
 

    



    
 

% mv y.o y.c a.out junk



  

  

    
 

    



    
 

% cd junk



  

  

    
 

# インクリメンタルリンク。現
在の作業ディレクトリは
/tmp/junk になっている。



    
 

% cc -xildon -z i_verbose y.o -o a.out



  

  

    
 

    



    
 

ild: (Performing full relink) current directory has 
changed from `/tmp' to `/tmp/junk'



  

  

    
 

    



    
 

%



  

  

    
 



    
 

<訳>


 

完全再リンクを実行します 


 

--  現在の作業ディレクトリが /tmp から /tmp/junk に変更さ
れました



  















   ild オプション






   この節では、リンカー制御オプション (直接コンパイラが受け取るオプションと、コンパイラによって ild に渡されるオプション) について説明します。






   -a






   静的モードのみで、実行可能オブジェクトファイルを作成します。未定義の参照にエラーを出します。静的モードのデフォルト動作です。






   -B dynamic | static






   ライブラリの取り込みを制御するオプションです。-Bdynamic は、動的モードでのみ有効です。この 2 つのオプションはコマンド行で何度でも指定でき、そのたびにモードを切り換えることができます。-Bstatic を指定している場合に共有オブジェクトを処理するには、-Bdynamic に切り替える必要があります。143 ページの「-lx」を参照してください。






   -d y|n






   -dy (デフォルト) を指定すると、動的リンク処理が実行されます。-dn を指定すると、静的リンク処理が実行されます。142 ページの「-B dynamic | static」を参照してください。






   -e epsym






   出力ファイルの入口点アドレスをシンボル epsym のアドレスに設定します。






   -g






   -g オプション (デバッグ情報の出力) を指定すると、コンパイラは ld の代わりに ild を実行します。次の条件が 1 つでも満たされている場合は -g オプションは使用できません。






   -I <名前>






   実行可能ファイルを作成するときは、プログラムヘッダーに書き込まれるインタープリタのパス名として <名前> を使用します。静的モードでのデフォルトはインタープリタなしです。動的モードでは、デフォルトは実行時リンカー /usr/lib/ld.so.1 の名前です。どちらの場合も、-I <名前> で無効にすることができます。exec システムコールは、a.out を読み込むときにこのインタープリタを読み込み、インタープリタに制御を渡します。a.out に直接渡すことはしません。






   -i






   LD_LIBRARY_PATH の設定を無視します。LD_LIBRARY_PATH の設定が有効なときに、実行中のリンク処理に干渉する実行時ライブラリの検索を変更する場合に使用します (これは LD_LIBRARY_PATH_64 の設定にも適用されます)。






   -L<パス>






   ライブラリ検索ディレクトリに <パス> を追加します。ライブラリは、最初にオプション -L で指定されたディレクトリで検索され、次に標準ディレクトリで検索されます。このオプションは、同じコマンド行上の -l オプションの前に指定した場合だけ有効です。環境変数 LD_LIBRARY_PATH と LD_LIBRARY_PATH_64 でも、ライブラリ検索パスを追加できます (148 ページの「LD_LIBRARY_PATH」を参照)。






   -lx






   ライブラリ libx.so または libx.a を検索します。これらはそれぞれ共有オブジェクトとアーカイブライブラリの一般的な名前です。動的モード、つまり -Bstatic オプションが指定されていないときは、ライブラリ検索パスに指定された各ディレクトリで、ファイル libx.so またはファイル libx.a を検索します。どちらかのファイルが含まれている最初のディレクトリで、検索は停止します。libx.so と libx.a という形式のファイルが両方ともある場合は、拡張子 .so が付いているファイルが使用されます。libx.so がない場合は、libx.a が使用されます。静的モードのとき、つまり -Bstatic オプションが指定されているときは、拡張子 .a が付いているファイルだけを使用します。ライブラリは、名前が検出された時に検索されるので、-l を指定するのは重要な意味があります。






   -m






   標準出力の入出力セクションのメモリーマップまたはリストを作成します。






   -o <出力ファイル>






   <出力ファイル> という名前の出力オブジェクトファイルを作成します。デフォルトのオブジェクトファイル名は a.out です。






   -Q y|n






   -Qy を指定すると、出力ファイルの .comment セクションに、出力ファイルの作成に使用したリンカーのバージョンを識別する ident 文字列が追加されます。この結果、複数回リンク処理を行なった場合は、ld -r を使用したときと同じように複数の ld idents が追加されます。これは cc コマンドのデフォルト処理と同じです。オプション -Qn を指定すると、バージョンを識別する ident 文字列は追加されません。






   -R<パス>






   実行時リンカーに渡されるライブラリ検索ディレクトリを、コロン (:) で区切られたリストで指定します。<パス> が存在しかつ空でない場合は、<パス> は出力オブジェクトファイルに記録され、実行時リンカーに渡されます。このオプションを複数回に分けて使用すると、指定された検索ディレクトリは連結されてコロンで区切られます。






   -s






   シンボル情報を出力ファイルに出力しません。デバッグ情報および対応する再配置エントリが出力されなくなります。再配置可能ファイルまたは共有オブジェクトファイル以外の出力ファイルには、シンボルテーブルと文字列テーブルのセクションも出力されなくなります。






   -t






   複数回定義され、しかもサイズが異なるシンボルに関する警告を出力しません。






   -u <シンボル名>






   <シンボル名> をシンボルテーブルに未定義シンボルとして記入します。これは、アーカイブライブラリをまるごと読み込むのに便利です。シンボルテーブルははじめは空であり、最初のルーチンを読み込むために未解決の参照が必要だからです。コマンド行でのこのオプションを指定する位置は重要です。このオプションは、シンボルを定義するライブラリの前に置かなければなりません。






   -V






   使用している ild のバージョンに関するメッセージを出力します。






   -xildoff






   インクリメンタルリンカーを使用せず、強制的に ld を実行します。-g オプションを指定しない場合、または -G オプションを指定した場合は、このオプションがデフォルトです。デフォルトを受け入れたくない場合は -xildon を指定してください。






   -xildon






   強制的に、ild を使用してインクリメンタルリンカーを実行します。-g オプションを指定した場合は、このオプションがデフォルトです。デフォルトを受け入れたくない場合は -xildoff を指定してください。






   -YP,<ディレクトリのリスト>






   (cc のみ) ライブラリを検索するデフォルトディレクトリを変更します。オプション <ディレクトリのリスト> には、ディレクトリのパスをコロンで区切って指定します。






   注 - -z <名前> という形は、ild で特殊なオプションを指定する場合に使用します。-z オプションの接頭辞として i_ を付けたものは、ild に固有のオプションとして識別されます。






   -z allextract|defaultextract|weakextract






   このオプションの後に続くアーカイブから、オブジェクトの抽出基準を変更します。デフォルトでは、未定義の参照を解決し、一時的な定義がデータ定義になるようにアーカイブメンバーが抽出されます。弱いシンボル参照のためには、抽出は行われません。-z allextract を指定すると、アーカイブからすべてのメンバーが抽出されます。-z weakextract を指定すると、弱い参照によってアーカイブ抽出が発生します。-z defaultextract は、それまでに使用されていた抽出オプションからデフォルトに戻ることを意味します。






   -z defs






   リンク終了時に未定義シンボルが残っている場合に、致命的エラーを出力します。実行可能ファイルの作成時はこれがデフォルトです。共有オブジェクトを作成し、シンボル参照がすべてオブジェクト内部で解決されるようにする場合に、このオプションを使用します。






   -z i_dryrun






   (ild のみ) リンクされるファイルのリストを出力して、処理を終了します。






   -z i_full






   (ild のみ) インクリメンタルモードで全体の再リンクを行います。






   -z i_noincr






   (ild のみ) ild をインクリメンタルでないモードで実行します (ユーザーによる使用はお勧めできません。テスト用にだけ使用してください)。






   -z i_quiet






   (ild のみ) ild 再リンクメッセージをすべて表示しません。






   -z i_verbose






   (ild のみ) 詳細情報モードを持つ ild 再リンクメッセージを拡張して、より詳細な情報を出力します。






   -z nodefs






   未定義シンボルがあってもエラーにしません。共有オブジェクトの作成時はこれがデフォルトです。実行可能ファイルの作成時には、未定義シンボルは参照されません。






   コンパイラから ild に渡されるオプション






   以下のオプションは ild によって認識されますが、コンパイラから ild に渡すときは次のどちらかの形式を使用する必要があります。






   -a






   静的モードのみで、実行可能オブジェクトファイルを作成します。未定義の参照にエラーを出します。静的モードのデフォルト動作です。オプション -a は、オプション -r と同時には指定できません。






   -m






   標準出力の入出力セクションのメモリーマップまたはリストを作成します。






   -t






   複数回定義され、しかもサイズが異なるシンボルに関する警告を出力しません。






   -e epsym






   出力ファイルの入口点アドレスをシンボル epsym のアドレスに設定します。






   -I <名前>






   実行可能ファイルを作成するときは、プログラムヘッダーに書き込まれるインタープリタのパス名として <名前> を使用します。静的モードでのデフォルトはインタープリタなしです。動的モードでは、デフォルトは実行時リンカー /usr/lib/ld.so.1 の名前です。どちらの場合も、-I <名前> で無効にすることができます。exec システムコールは、a.out を読み込むときにこのインタープリタを読み込み、インタープリタに制御を渡します。a.out に直接渡すことはしません。






   -u <シンボル名>






   <シンボル名> をシンボルテーブルに未定義シンボルとして記入します。これは、アーカイブライブラリをまるごと読み込むのに便利です。シンボルテーブルははじめは空であり、最初のルーチンを読み込むために未解決の参照が必要だからです。コマンド行でのこのオプションを指定する位置は重要です。このオプションは、シンボルを定義するライブラリの前に置かなければなりません。






   環境変数






   LD_LIBRARY_PATH



  

     
  -l オプションで指定されたライブラリを検索するディレクトリのリストです。複数のディレクトリはコロンで区切ります。通常は、1 つのセミコロンで区切られた 2 つのディレクトリのリストが指定されています。



  
  

    
 

     <ディレクトリのリスト1>; <ディレクトリのリスト2>



  









     
  以下のように、-L を任意の回数指定して ild を呼び出すとします。



  
  

    
 

  ild ...-L<パス1> ...  -L<パスn> ...



  









  




   この場合、検索パスの順序は以下のようになります。



  
  

    
 

  <ディレクトリのリスト1> <パス1> ...  <パスn> <ディレクトリのリスト2>  
LIBPATH



  















   ディレクトリのリストにセミコロンが入っていないときは、次のように解釈されます。



  
  

    
 

  <ディレクトリのリスト2>



  















   LD_LIBRARY_PATH は、実行時リンカーにライブラリ検索ディレクトリを指定するのにも使用します。つまり、LD_LIBRARY_PATH が指定されていると、実行時リンカーは、実行時にプログラムとリンクされる共有オブジェクトを、LD_LIBRARY_PATH に指定されたディレクトリで検索してから、デフォルトのディレクトリで検索します。






   注 - set-user-ID プログラムまたは set-group-ID プログラムを実行するときは、実行時リンカーは /usr/lib 内のライブラリと、実行可能ファイル内に指定された絶対パス名を検索します。この絶対パス名は、実行可能ファイルが作成されるときに指定された実行時パスです。相対パス名で指定されたライブラリ関係は暗黙的に無視されます。






   LD_LIBRARY_PATH_64



  

     
  Solaris 7 と Solaris 8 で使用されます。この環境変数は LD_LIBRARY_PATH に似ていますが、64 ビットの依存関係を検索する場合に LD_LIBRARY_PATH を無効にします。
     
  Solaris 7 または Solaris 8 を SPARC プロセッサ上で実行し、32 ビットモードでリンクする場合、LD_LIBRARY_PATH_64 は無視されます。LD_LIBRARY_PATH しか定義しなかった場合は、32 ビットリンクと 64 ビットリンクの両方に LD_LIBRARY_PATH が使用されます。LD_LIBRARY_PATH と LD_LIBRARY_PATH_64 の両方を定義すると、32 ビットリンクは LD_LIBRARY_PATH を使用して行われ、64 ビットリンクは LD_LIBRARY_PATH_64 を使用して行われます。
  




   LD_OPTIONS



  

     
  ild のデフォルトのオプションです。LD_OPTIONS の値は、ild を起動するコマンドの直後に入力されたものとして解釈されます。 



  
  

    
 

  ild $LD_OPTIONS   ...  <その他の引数> ...



  









  




   LD_PRELOAD






   実行時リンカーによって解釈される共有オブジェクトのリストです。指定された共有オブジェクトは、実行中のプログラムの後、プログラムが参照する他の共有オブジェクトの前にリンクされます。






   注 - set-user-ID プログラムまたは set-group-ID プログラムを実行するときは、このオプションは暗黙的に無視されます。






   LD_RUN_PATH



  

     
  リンカーに実行時パスを指定するもうひとつの方法です (-R オプションを参照)。LD_RUN_PATH と -R オプションの両方を指定すると、-R で指定したパスが使用されます。
  




   LD_DEBUG



  

     
  (ild ではサポートされていません) 実行時リンカーによって標準エラーにデバッグ情報が出力されるように、トークンのリストを指定します。トークンとして help と指定すると、使用できるすべてのトークンが表示されます。



   注 - LD_ で始まる環境変数名は、ld の将来の拡張用に予約されています。ILD_ で始まる環境変数名は、ild の将来の拡張用に予約されています。



  




   注意事項






   サポートされていないコマンド行オプションを指定すると、ild は /usr/css/bin/ld を呼び出してリンクを実行します。






   ild で使用できない ld オプション






   以下のオプションはコンパイラに指定することはできますが、現在 ild でサポートされていません。






   -B symbolic






   動的モードのみで使用します。定義が使用できる場合は、共有オブジェクトの作成時に、大域シンボルの参照をオブジェクト内の定義に結合します。通常、共有オブジェクト内の大域シンボルの参照は、定義を使用できても実行時まで結合されないので、実行可能ファイルまたは他の共有オブジェクト内の同じシンボルの定義によって、オブジェクト自体の定義が無効になることがあります。未定義シンボルがあると ld によって警告メッセージが出力されます (-z defs を指定すると警告メッセージは出力されません)。






   -b






   動的モードのみで、実行可能ファイルを作成するときに、共有オブジェクト内のシンボルを参照する再配置用の特殊処理を行わないようにします。-b オプションを指定しないと、リンカーは、共有オブジェクト内に定義された関数参照のために位置独立の特殊な再配置コードを作成し、共有オブジェクト内に定義されたデータオブジェクトが実行可能ファイルのメモリーイメージ内に実行時リンカーによってコピーされるようにします。-b オプションを指定すると、出力コードは効率的になりますが、共有性は低下します。






   -G






   動的モードのみで使用し、共有オブジェクトを作成します。未定義シンボルも使用できます。






   -h <名前>






   動的モードのみで使用します。共有オブジェクトの作成時に、共有オブジェクトの動的セクション内に <名前> を記録します。<名前> は、オブジェクトの UNIX ファイル名としてではなく、オブジェクトとリンクされる実行可能ファイル内に記録されます。そのため <名前> は、実行時リンカーが実行時に検索する共有オブジェクト名として使用されます。






   -z muldefs






   複数のシンボル定義を行うことができるようにします。デフォルトでは、再配置可能オブジェクトの間に複数のシンボル定義があると致命的エラーになります。このオプションを指定すると、複数のシンボル定義をエラーにせず、最初のシンボル定義が使用されます。






   -z text






   動的モードのみで使用します。書き込み禁止の割り当て可能セクションに対する再配置が残っている場合に、致命的エラーにします。






   サポートされないその他のコマンド






   また、以下のオプションは直接 ld に渡され、ild にはサポートされていません。






   -D <トークン>,<トークン>, ...






   各トークンで指定したように、デバッグ情報を標準エラーに出力します。トークンとして help を指定すると、使用できるすべてがトークンが表示されます。






   -F <名前>






   共有オブジェクトの作成時のみ使用します。共有オブジェクトのシンボルテーブルが、<名前> で指定した共有オブジェクトのシンボルテーブルの「フィルタ」として使用されるように指定します。






   -M <マップファイル>






   <マップファイル> を、ld に対する指示テキストファイルとして読み取ります。マップファイルについての詳細は、『リンカーとライブラリ』を参照してください。






   -r






   再配置可能なオブジェクトファイルを組み合わせ、1 つのオブジェクトファイルを作成します。ld は解釈されない参照があってもエラーとしません。このオプションは、動的モードでは使用できません。また、-a オプションと同時に使用することはできません。






   ild で使用するファイル






   libx.a ライブラリ






   a.out 出力ファイル






   LIBPATH (通常は /usr/lib)






   

















サン・マイクロシステムズ株式会社

Copyright information. All rights reserved.






ホーム
  |  
目次
  |  
前ページへ
  |  
次ページへ
  |  
索引