Next: Cheap tricks, Previous: Platform quirks, Up: Maintaining
libtool
スクリプトの内容
バージョン1.4からは,libtool
スクリプトはconfigure
によっ
て生成されます(see Configuring.以前のバージョンでは,
ltconfig と呼ばれるへルパースクリプトを呼び出すことで,
configure
はそれを達成していました.libtoolのバージョン0.7から
1.0までは,このスクリプトは,単純にシェル変数を設定し,libtoolのバック
エンドのltmain.sh
の源となっていました.libtoolバージョン1.1から
1.3までのltconfig
は,ltmain.sh
の内容を,生成された
libtool
にインライン化し,それは多くのシステムでパフォーマンスを
改善しました.ltconfigが実行するために使用するテストは,現在
libtool.m4にあり,そこで我々はAutoconfを使用して書くことが可能
となっています.これは,インライン化されたltmain.sh
の実行時の動
作に有利で,そして,管理が必要な生のシェルコードの量をかなり取
り除くことで,ビルド時間を短くする改善を行いました.
後で評価するもの対するシェルコマンドを保持する変数の命名に使用される規
則は,有効な単一行のシェルスクリプトが必要とされるところで接尾子
_cmd
,複数行のシェルスクリプトが後で評価することが可能
なところで接尾子_cmds
を使用することです.規則では,
_cmds
変数は,必要なところで,~
文字で評価ユニットを区切り
ます.
それぞれのコンフィグレーション変数と,ltmain.sh
で使用する方法の
リストは,以下のようになります(see Configuring).
BSD互換の
nm
プログラムの名前で,それは以下の書式の一つで,大域的 なシンボルを生成します.address C global-variable-name address D global-variable-name address T global-function-name
結果として生じる共有ライブラリに,未解決のシンボルがあることを宣言する ために,‘archive_cmds’で使用されるフラグです.そのようなフラグが 不要な場合は空です.ライブラリで定義されていないシンボルを参照して,共 有ライブラリを生成する方法がない場合,‘unsupported’を設定します.
アーカイブとリンクする前に,export_symbols_cmdsを使用してエクス ポートされるシンボルのリストを,libtoolが自動的に生成するかどうかです. ‘yes’または‘no’に設定します.デフォルトは‘no’です.
それぞれ,共有ライブラリ,‘-export-symbols’を用いた共有ライブラリ, そしてスタティックライブラリを生成するために使用するコマンドです.
共有ライブラリがスタティックライブラリに依存する場合, ‘old_archive_from_new_cmds’はスタティックライブラリを生成するため に使用するコマンドを含みます.この変数が空の場合, ‘old_archive_cmds’は使用されません.
スタティックライブラリが,共有ライブラリで正しくリンクするために,エク スポートシンボルリストから作成される必要がある場合, ‘old_archive_from_expsyms_cmds’は,そのスタティックライブラリを作 成するために必要なコマンドを含みます.これらのコマンドが実行されるとき, 変数sonameは,共有ライブラリの名前を疑問符の中に含み, $objdir/$newlibは,これらのコマンドがビルドするスタティックライ ブラリのパスを含みます.これらのコマンドを実行した後,libtoolは, sonameの代わりに$objdir/$newlibに対してリンクするための処 理を行います.
コンパイラが,直接".lo"ファイルへのコンパイルをサポートするかどうかで, 例えば,オブジェクトファイルが,接尾子".o"を持つ必要があるかどうかです. ‘yes’または‘no’に設定します.
スタティックにリンクされているとき(‘-all-static’),実行形式自身が
dlopen
可能かどうかです.‘yes’または‘no’に設定します.
共有ライブラリからエクスポートされたシンボルリストを抽出するコマンドで す.これらのコマンドは,ファイル$objdir/$soname-defが無い場合に 実行され,‘old_archive_from_expsyms_cmds’が使用するため,エクスポー トされたシンボル名をそのファイルに書き出します.
libtoolが特権を与える人を,インストール者または開発者のどちらかに決定 します.インストール者がビルドツリーでプログラムを実行することは滅多に なく,開発者は滅多にインストールしないしないと仮定します.これは, shlibpath_overrides_runpathが‘yes’でないプラットフォーム上 でのみ意味があるので,この場合,fast_installは‘needless’設 定されます.fast_installが‘yes’に設定される場合,libtoolは インストールされたライブラリを検索するプログラムを作成し,プログラムが ビルドツリーで実行される場合,まだインストールされていないライブラリを 使用するため,要求があれば,新しいコピーがリンクされます.‘no’に 設定されている場合,libtoolは,まだインストールされていないライブラリ を使用するプログラムを作成し,インストール時にプログラムの新しいコピー をリンクします.デフォルト値は‘yes’または‘needless’で,それ は,プラットフォームとコンフィグレーションフラグに依存し,コンフィグレー ションフラグ‘--disable-fast-install’を用いると,‘yes’から ‘no’に切り替えられます.
NMの出力を受け,Cの名前が続く生のシンボルのリストを生成するパイ プラインです.例えば,以下のようになります.
$ eval "$NM progname | $global_symbol_pipe" D symbol1 C-symbol1 T symbol2 C-symbol2 C symbol3 C-symbol3 ... $最初の列は,(いくつかのプラットフォーム上でコードからデータを伝えるた めに使用される)シンボル形式を含みますが,その意味はシステムに依存しま す.
global_symbol_pipeの出力を厳密なC宣言に変換するパイプラインです. HP/UXのような,リンカがコードとデータを区別するプラットフォームでは, データシンボルはそのように宣言され,コードシンボルは関数として宣言され ます.気にしないプラットフォームではすべてがデータと仮定されます.
‘immediate’または‘relink’のいずれかで,共有ライブラリパスが インストールされる前に実行形式にハードコードされるか,または,再リンク する必要があるかに依存します.
hardcode_libdir_flag_specが指定されたとき, (‘dir/libname.a’のような)コマンド行でライブラリが直接 していされる場合,リンカがディレクトリをハードコードするかどうかに依存 し,‘yes’または‘no’に設定します.
ライブラリ内の実行パスのハードコードをプラットフォームがサポートするか どうかです.可能な場合,プログラムのリンクはより単純になりますが,ライ ブラリはインストール時に再リンクが必要です.‘yes’または‘no’ に設定します.
実行時に,共有ライブラリに対しダイナミックリンカがlibdirを検索す るために,バイナリにlibdir変数をハードコードするためのフラグです. 空の場合,libtoolは他のハードコーディングメカニズムの使用を試みます.
コンパイラが単一のhardcode_libdir_flagのみ受け入れる場合,この変 数はそのフラグに対する複数の引数を分ける文字列を含みます.
hardcode_libdir_flag_specが指定されたとき,結果として生じる実行 形式に‘-L’フラグで指定されるディレクトリを,リンカがハードコード するかどうかに依存し,‘yes’または‘no’に設定します.
hardcode_libdir_flag_specが指定されたとき,結果として生じる実行 形式に‘$shlibpath_var’の内容を書き込むことで,リンカがディレクト リをハードコードするかどうかに依存し,‘yes’または‘no’に設定 します.‘$shlibpath_var’で指定されたディレクトリが,リンク時では なく実行時に検索される場合,‘unsupported’に設定します.
ライブラリ名の接頭辞の書式です.Unixシステムでは,スタティックライブラ リは‘libname.a’と命名されますが,(OS/2やMS-DOSのような)シス テムでは,ライブラリは‘name.a’のみで命名されることもありま す.
共有ライブラリ名のリストです.最初はファイル名で,残りはファイルへのシ ンボリックリンクです.リスト内の名前は,‘-lname’で与えられ たときリンカが見つけるファイル名です.
libtoolが,全ての依存するプログラムに対しプログラムをリンクする必要が あるかどうかです.‘yes’または‘no’に設定します.デフォルトは ‘unknown’で,それは‘yes’と同じです.
自動的にモジュール名に'lib'接頭辞を付けるかどうかです.‘yes’また は‘no’に設定します.デフォルトで,それは‘unknown’になり,そ れは‘yes’と同じ意味ですが,本当に確かめたわけではないことを告げて います.‘yes’は
dlopen
と'lib'接頭辞がないライブラリにリンク 可能なことを意味し,すなわち,それはhardcode_directを‘yes’ にすることを要求します.
バージョン管理がライブラリに必要とされるかどうかで,すなわち,ダイナミッ クリンカが,すべてのライブラリに対しバージョンの接尾子を必要とするかど うかです.‘yes’または‘no’に設定します.デフォルトで,それは ‘unknown’で,それは‘yes’と同じ意味を持ちますが,それを実際に は確かめていないことを告げています.
それぞれ,共有またはスタティックライブラリをインストールした後に実行す るコマンドです.
それぞれ,共有またはスタティックライブラリをアンインストールした後に実 行するコマンドです.
環境変数でプログラムのハードコードされたライブラリ検索パスを優先可能か どうかを示します.これが‘no’に設定されている場合,libtoolはビルド ツリーにプログラムのコピーを二つ作成する必要がある可能性があり,一つは インストールされ,もう一つはビルドツリーのみで実行されます.これらのコ ピーのどちらかが作成されるとき,
fast_install
の値に依存します. デフォルト値は‘unknown’で,それは‘no’と同じです.
共有(
striplib
)やスタティック(old_striplib
)のライブラリを stripするコマンドです.これらの変数が空の場合,インストールモードの stripフラグは,ライブラリに対し無視されます(see Install mode).
実行時にライブラリの検索パスを取得する式です.このリストに現れるディレ クトリが実行形式にハードコードされることは決してありません.
コンパイル時にライブラリの検索パスを取得する式です.この変数は,特定の ライブラリが共有かスタティックかをテストする必要があるとき,libtoolが 使用します.shlibpath_varでリストアップされるディレクトリは,こ のリストに自動的に現れ,ライブラリ検索パスを拡張するためにこの変数を使 用するリンカもあるので,毎回(すなわち,コンフィグレーション時以外) libtoolは実行します.リンカは
-L
のような検索パス引数も切り替えま す.
ライブラリバージョンナンバーの形式です.‘libtool’, ‘freebsd-aout’,‘freebsd-elf’,‘irix’,‘linux’, ‘osf’,‘sunos’,‘windows’,または‘none’の一つです.
‘_cmds’や‘_eval’で終わる変数は,‘~’で分けられた,順番に
eval
されるコマンドのリストを含みます.ゼロ以外の終了ステータス
を返すコマンドがある場合,libtoolは一般的にエラーメッセージとともに終
了します.
‘_spec’で終わる変数は,libtoolで使用される前にeval
されます.