[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
これまで,ソースコードパッケージの開発者が共有ライブラリの能力を利用し たい場合,パッケージを実行するそれぞれのプラットフォームに対し,カスタ ムサポートコードを書く必要がありました.パッケージインストーラがビルド されるライブラリの種類を選択できるように,コンフィグレーションインター フェースを設計する必要もありました.
GNU Libtoolは,一つのスクリプトでプラットフォーム特有の依存性とユーザ インターフェースの両方をカプセル化することで,開発者の仕事を単純にしま す.GNU Libtoolは,それぞれのホストの形式の完全な機能を,一般的なイン タフェースを通して利用できるが,やっかいな癖はプログラマから隠されるよ うに設計されています.
GNU Libtoolの一貫したインターフェースは再保証されます… ユーザは
好みのソースコードパッケージを共有ライブラリにビルドするため,不明瞭な
ドキュメントを読む必要がありません.パッケージのconfigure
スクリ
プト(またはその同等品)を実行するだけで,libtoolがいやな仕事をすべて行っ
てくれます.
このドキュメント全体にいくつかの例があります.すべて同じ環境を仮定して います.我々は,ライブラリ`libhello'を一般的な方法でビルドしたい と思っています.
`libhello'は,共有ライブラリ,スタティックライブラリ,または,そ の両方になります… libtoolで移植できるホストシステムで利用可能な すべてのものです.
この章では,libtoolの最初の設計思想を説明します.歴史に興味がなかった り,堅実な方法で拡張されているlibtoolのコードを書きたい場合,自由に飛 ばして次の章へ行ってください.
1.1 libtoolを書いた動機 | Why does GNU need a libtool? | |
1.2 問題の実装 | The problems that need to be addressed. | |
1.3 その他の実装 | How other people have solved these issues. | |
1.4 その他の実装の近代的な解析 | Learning from past difficulties. |
1995年初頭から,数人のGNU開発者はそれぞれ,パッケージに対する共有ライ ブラリのサポートの重要性を認識していました.そのように変更する主な動機 は,GNUプログラムでのコードのモジュール化と再利用を(概念的,物理的の両 方で)促進するためです.
そのような要求は,パッケージのインストーラが要求するすべてのライブラリ の形式が可能になるように,GNUパッケージにライブラリを組み込む方法を一 般的なものにする必要があることを意味します.問題は,異なるプラットフォー ムで共有ライブラリを作成する標準的な手法が無いことです.
以下のセクションで,GNUでの共有ライブラリのサポートが直面している重大 な問題と,共有ライブラリのサポートをlibtoolで標準化した方法を概説しま す.
以下の仕様書が,このシステムの開発と評価で使用されました.
システムはできる限り簡潔である必要があります.
システムは,GNU管理者がより簡単に使用できるように,GNU Autoconfと Automakeユーティリティと完全に統合する必要があります.しかし,GNUパッ ケージ以外でも使用できるように,これらのツールを要求してはなりません.
他の(GNUでない)アーキテクチャとツールへの移植が望まれます.
以下の問題は,再利用可能なあらゆる共有ライブラリシステム,特にlibtool で解決する必要があります.
パッケージのインストーラで,ビルドされるライブラリの種類を制御可能にす べきです.
インストールされていないライブラリとダイナミックにリンクされるプログラ
ムの実行を巧妙に行うことを可能にします.LD_LIBRARY_PATH
が(サポー
トしている場合は)正しく設定されている必要があり,そうでなければプログ
ラムの実行に失敗するでしょう.
システムは,共有ライブラリをサポートしていないホストでさえ,堅実に処理 する必要があります.
共有ライブラリをビルドするときに必要なコマンドは,ホストごとに大きく異 なる可能性があります.これらは,コンフィグレーション時に一定の方法で決 定する必要があります.
インストールされる共有ライブラリの接尾子が常に明確なわけではありません. 通常,ファイル名はホストごとに同じだということを仮定されるので, `Makefile'規則が難しくなります.
共有ライブラリをその場でアップグレード可能なように,システムは,単純な ライブラリバージョンナンバーの抽象化が必要です.バイナリ互換を最大にす るため,ライブラリへのインターフェースの設計方法を,プログラマに伝える べきです.
インストールする`Makefile'ターゲットは,パッケージインストーラに
特定の環境変数(LD_LIBRARY_PATH
または同等のもの)を設定したり,
ldconfig
を実行するよう,警告する必要があります.
libtoolが開発されるまで,多くのフリーソフトウエアパッケージは,独自の 共有ライブラリをビルドしインストールしていました.既存の機能の再発明を 避けるために,これらのパッケージを最初に調査しました.
さて,これらのパッケージに,libtoolが必要としている共有ライブラリシス テムの詳細な文章が無いのは明らかです.そのため,それ以外のパッケージは 影響するので多少断念されました.
調査されたそれぞれの実装は,多くの異なるホストシステムに対して,予定し ていた仕事をすべて公平に行いました.しかし,再利用できるコンポーネント として一般的に機能するものは,これらの解決法にはないようでした.
ほとんどのものは,実装で行なわれていることを正確に理解すること無く使用 する(まして,変更する)には複雑すぎ,それらは通常,文章化されていません でした.
異なるベンダーはライブラリについて異なる見解を持つこと,そして,当然 動作するという単一のパラダイムを自信を持って定めているものが調 査したパッケージには無かったことが主な難点です.
理想としては,既存のライブラリシステムが一貫して動作するような一連の拡 張と変更として実装されている標準物に,libtoolがなることです.しかし, オペレーティングシステム開発者に悪い方法を修正させることは簡単な仕事で はなく,バグが多く,壊れていて,混乱したオペレーティングシステム上でさ え,今すぐに共有ライブラリをビルドしたいと,人々は思っていました.
このため,libtoolは独立したシェルスクリプトとして設計されました.それ は,異なるプラットフォーム上のコンパイラスイートを,堅実で強力なインター フェースを用いて包み隠すことで,`Makefile'の書き手を悩ませるライ ブラリのビルドでの問題と矛盾から隔離しています.
運が良ければ,libtoolは役に立ち,GNUコミュニティで使用され,そして,そ れを書くとき学んだ教訓は,将来のライブラリシステムの設計に採用されるで しょう.
[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated by Akihiro Sagawa on June, 15 2005 using texi2html 1.70.