オブジェクトライブラリは、ar ライブラリアーカイブ に含まれている複数のオブジェクトファイルの集まりです (ライブラリアーカイブファイルについての詳細は、ar(1) および lorder(1) のマニュアルページを参照してください)。多くの言語では、C のライブラリにあるような汎用ユーティリティのコンパイル済み関数をオブジェクトライブラリとして保存します。
ar は、1 つまたは複数のファイルを読み込んでライブラリを作成します。ライブラリに含める各メンバーには、ヘッダーと 1 つのファイルのテキストが含まれます。メンバーのヘッダーには、ファイルディレクトリのエントリから取得した、変更時間などの情報が含まれます。これによって、make は依存関係の検査で、ライブラリのメンバーを独立した別々の構成要素として扱うことができます。
オブジェクトライブラリの関数を使用するプログラムを (ファイル名または cc の -l オプションにより適切なライブラリを指定して) コンパイルすると、リンカーは必要なシンボルを含むライブラリのメンバーを選択してリンクします。
ar を使用して、オブジェクトファイルのライブラリ用のシンボルテーブルを生成できます。ld がライブラリ内のシンボルへアクセスできるように、つまり関数が定義されたオブジェクトファイルを ld が検出してリンクできるようにするには、このシンボルテーブルが必要です。また、先に lorder と tsort を使用して、メンバーを呼び出し順にライブラリ内でソートすることもできます (詳細は、ar(1) および lorder(1) を参照してください)。大規模なライブラリでは、これら両方の処理を行なってください。
make は、以下の形式で記述されたターゲットまたは依存関係を、ライブラリのメンバーへの参照または複数のメンバーを空白文字で区切ったリストへの参照として認識します。
lib.a (member . . . )
旧バージョンの make は、上記の書式を認識しますが括弧内の最初のメンバーだけが処理されます。
このバージョンの make では、括弧内に指定したすべてのメンバーが処理されます。たとえば次に示すターゲットエントリは、librpn.a というライブラリが、stacks.o および fifos.o というメンバーから構築されることを示しています。またパターンマッチングの規則は、各メンバーは対応するオブジェクトファイルに依存していて、オブジェクトファイルは対応するソースファイルから暗黙の規則を使用して構築されることを示しています。
librpn.a: librpn.a (stacks.o fifos.o) ar rv $@ $? $@ librpn.a (%.o): %.o @true
ライブラリのメンバーを記述する際には、動的マクロの $?
は対応するメンバーよりも新しいファイルのリストを示します。
$ make cc -c stacks.c cc -c fifos.c ar rv librpn.a stacks.o fifos.o a - stacks.o a - fifos.o
$%
動的マクロ $%
は、特にライブラリの指定に使用します。ライブラリのメンバーがターゲットの場合は、メンバーの名前が $%
マクロに割り当てられます。たとえば、libx.a(demo.o) というターゲットが指定されている場合は、$%
の値は demo.o になります。
通常は、ターゲットの処理中に make に割り込みが発生すると、ターゲットファイルが削除されます。これは、変更時間が最新になった不完全なファイルがディレクトリに残らないようにするため、1 つずつ独立したライブラリファイルの場合に適しています。しかし、複数のメンバーで構成されるライブラリの場合は、最新でないメンバーがあってもライブラリファイルを削除せずにそのままにしておくことをお勧めします。以降に make を実行すると、前回の実行で処理が中断されたオブジェクトファイルまたはメンバーから処理が継続されるため、特に大規模なライブラリの場合は、ライブラリファイルを削除しないでおくことをお勧めします。処理時間を節約することができます。
.PRECIOUS という特殊ターゲットは、割り込み時の削除から保護するファイルを指定するために使用します。make は、このターゲットの依存関係として指定されたターゲットは削除しません。
.PRECIOUS: librpn.a
たとえば、この行を前述のメークファイルに追加して make を実行すると、librpn.a の処理に割り込んだ場合は、ライブラリは削除されません。