[ << ] | [ >> ] | [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.