7.6.1 tsort: 誕生の背景

tsort が存在しているのは、Unix のリンカのごく初期のバージョンでは、 一つのアーカイブファイルの処理をたった一回しか行わず、 それも、ファイルの最初から最後へと順番に見ていくだけだったからである。当時の ld は、アーカイブ中の各オブジェクトを読み込むとき、 そのオブジェクトがプログラムに必要かどうかの判断を、 リンク作業のその時点でまだ定義されていない何らかのシンボルを定義しているかどうかを基準にして行っていた。

そのため、アーカイブ中の依存関係には、特別な扱いが必要になった。 たとえば、scanf はたぶん read を呼んでいる。 それは、リンカがアーカイブをたった一回最初から順番に読んで行くとき、scanf.o が read.o より前にあることが重要だったということである。 なぜなら、そうなっていないと、scanf を呼ぶけれど、read を呼ばないプログラムでは、read に対する参照が、予期に反して "unresolved" になってしまいかねなかったからだ。

この問題に対処する方法は、次のようなものだった。 まず、オブジェクトファイル同士の依存関係の集合を生成した。 この作業は、lorder というシェルスクリプトによって行われていた。 筆者の知るかぎり、現在 GNU では lorder というツールを提供していないが、 BSD 系のディストリビューションでは、今でもなお見つけることができる。

次に、この　lorder の出力に対して tsort を実行した。 そして、そのソートされた結果を使って、アーカイブにオブジェクトを追加する順番を決めたのである。

こうした作業全体が、1980 年ごろから時代遅れのものになった。 というのは、Unix のアーカイブは現在ではシンボル・テーブルを内蔵しており (従来は ranlib によって作られていたが、今ではたいてい ar そのものによって作られている)、Unix のリンカはこのシンボル・テーブルを使用して、 アーカイブファイルに対する複数回の読み込みを効率的に行うからである。

ともあれ、これが tsort が誕生した経緯である。 すなわち、当時のリンカのアーカイブファイルを取り扱う方法に問題があり、 その問題を解決するための工夫だったのだ。 そして、その問題は、その後、別のやり方で解決されるようになったのである。

This document was generated on June 7, 2022 using texi2html 1.82.