Provided by: manpages-ja_0.5.0.0.20161015+dfsg-1_all 

名前
libtool - ライブラリのコンパイル・ビルド・ インストール・アンインストールをする
書式
libtool [-n] [--config] [--debug] [--dry-run] [--features] [--finish] [--mode=MODE] [--quiet] [--silent] [MODE-ARGS...] リンクモード: [-lNAME] [-o OUTPUT-FILE] [-LLIBDIR] [-R LIBDIR] [-all-static] [-avoid-version] [-dlopen FILE] [-dlpreopen FILE] [-export-dynamic] [--export-symbols FILE] [--export-symbols REGEX] [--module] [-no-undefined] [-release RELEASE] [-rpath LIBDIR] [-static] [-version-info CURRENT[:REVISION[:AGE]] 実行モード: [-dlopen FILE] libtool [--features] [--help] [--version]
説明
libtool は静的ライブラリや共有ライブラリの コンパイル・リンク・インストール・アンインストールの複雑さを簡 略化する。 異なるプラットフォームそれぞれで、完全な機能を 統一的なインターフェースを介して使用することが でき、 プラットフォーム固有の厄介な癖はプログラマーから隠蔽される。 libtool はコンパイル・実行・リンク・フィニッシュ・インストール・アンインストール という 6 つのモードで動 作できる。 コンパイルモード コンパイルモードの場合、MODE-ARGS は 標準的なオブジェクトファイルを作成するために使われる コンパイラコマ ンドである。 これらの引き数は C コンパイラの名前で始まり、 オブジェクトファイルのみを作成するよう、 -c コ ンパイラフラグを含んでいなければならない。 libtool は出力ファイルの名前を決定するとき、 ソースファイル名からディレクトリ構成要素を取り除き、 それか ら C 言語のソースコードの拡張子 `.c' をライブラリオブジェクトの 拡張子 `.lo' に置き換えるという方法を用い る。 共有ライブラリがビルドされる場合、必要な PIC 作成フラグすべてが コンパイルコマンドに挿入される。 -static オプションを指定すると、たとえ --disable-static が 設定されていたとしても、libtool は `.o' ファイルを作成 する。 -o オプションが直接サポートされていないプラットフォーム上では (コンパイラによって作成されたオブジェクト ファイルのロックと移動により) エミュレートを行う。 したがって、以下のような通常の構文を使うことができる。 lightside:% libtool cc -c foo/x.c -o foo/x.lo プラットフォームが -c と -o オプションをサポートしていない場合、 古い `foo/x.o' を上書きせずに `foo/x.lo' をビルドすることはできない。 この場合、`foo/x.o' が `foo/x.lo' の後に (再) ビルドされることを 確かめてお かなければならない。 リンクモード リンクモードはライブラリや実行可能プログラムを作成するために、 オブジェクトファイル (ライブラリオブジェク トも含む) をリンクする。 MODE-ARGS は、C コンパイラがオブジェクトファイルから (-o フラグにより) 出力ファイル OUTPUT-FILE を作成す る ときに使用するコマンドで構成される。 以下のように、ファイルの形式は OUTPUT-FILE の拡張子に依存する。 .la libtool ライブラリを作成する。 このライブラリはライブラリオブジェクト (`.lo' ファイル) のみからビ ルドされなければならない。 -rpath オプションが必要である。 現在の実装では、libtool ライブラリはア ンインストールされた他の libtool ライブラリに依存できない。 .a ar(1) と (あるいは) ranlib(1) を使って 標準ライブラリが作成される。 .o .lo (一般には `ld -r' を使うことで) 入力ファイルから 再ロード可能なオブジェクトファイルが作成される。 この手法は ``部分リンク'' と呼ばれることが多い。 other 実行可能なプログラムが作成される。 実行モード 実行モードでは、ライブラリパスの環境変数が自動的にセットされ (そして -dlopen によって修正されて)、プログ ラムが実行される。 一番目の MODE-ARGS はプログラム名として扱われ、 残りはプログラムの引数として扱われる。 引数の中のどれかが libtool 実行ファイルのラッパーであった場合、 その引数はそれぞれ対応するアンインストー ル済みバイナリの名前に変換される。 このとき、必要とされるライブラリディレクトリがライブラリパスに加えられ る。 インストールモード インストールモードでは、MODE-ARGS を cp(1) もしくは BSD-互換の install(1) から始まる インストールコマンド として解釈する。 残りの MODE-ARGS は、インストールコマンドの 引数として解釈される。 このコマンドは実行され、 インストール後の処理に必要な非特権コマンドもすべて完了する。 フィニッシュモード フィニッシュモードは、システム管理者の libtool ライブラリ インストール作業を補助し、 libtool ライブラリの 探索およびユーザー プログラムへのリンクができるようにする。 MODE-ARG はライブラリディレクトリ名として解釈される。 このコマンドを実行するのにはスーパーユーザー特権が 必要なため、 --dry-run オプションを使うと便利だろう。 アンインストールモード このモードではインストールされたライブラリ (もしくはファイル) を削除する。 一番目の MODE-ARG はファイルを削除するためのプログラム名 (一般には `/bin/rm') である。 残りの MODE-ARGS は削除プログラムの (`-' で始まる) フラグもしくは、 削除するファイルの名前である。
オプション
グローバルオプション --config libtool の設定変数を表示して終了する。 --debug シェルスクリプトのトレースモードを有効にして、標準出力に書き出す。 -n, --dry-run ファイルの作成・修正・削除を行わず、libtool によってどのような コマンドが実行されるかを表示する。 --features libtool の基本的な特徴を表示する。 また静的ライブラリと共有ライブラリが有効になっているかを表示す る。 --finish --mode=finish と同じ。 --mode=MODE MODE をオペレーションモードとする。 デフォルトでは、オペレーションモードは MODE-ARGS の内容から推 論される。 MODE を指定する場合、次のうちの一つでなければならない。 compile ソースファイルを libtool オブジェクトにコンパイルする。 execute 他のプログラムがアンインストールされたプログラムやライブラリ (libtool により作成されたもの) を使うことができるように、 ライブラリパスを自動的に設定する。 finish システムへの libtool ライブラリのインストールを完了する。 install ライブラリや実行ファイルをインストールする。 link ライブラリや実行ファイルを作成する。 uninstall ライブラリや実行ファイルを削除する。 --features libtool の設定情報を表示して終了する。 このオプションを使うと、パッケージは共有ライブラリと静的ラ イブラリの どちらを作るか決定できる。 --help 使用法のメッセージを標準出力に表示して、正常終了する。 --mode=MODE が指定されている場合は、 指定さ れたモードについてのヘルプが表示される。 --version バージョン情報を標準出力に表示して、正常終了する。 リンクモードオプション -lNAME OUTPUT-FILE はインストール済みの ライブラリ libNAME を必要とする。 このオプションは OUTPUT-FILE が 実行ファイルでなくても必要とされる。 -o OUTPUT-FILE 指定したオブジェクトとライブラリから OUTPUT-FILE を作成する。 -LLIBDIR 必要なインストール済みライブラリを LIBDIR から検索する。 -R LIBDIR OUTPUT-FILE が実行ファイルの場合は LIBDIR を実行時パスに加える。 OUTPUT-FILE がライブラリの場合は `-RLIBDIR' を DEPENDENCY_LIBS に加える。 これは、そのライブラリが実行ファイルにリンクされるときに 必ず LIBDIR を実行ファイルの実行時パスに加えるためである。 -all-static OUTPUT-FILE がプログラムの場合は、 そのプログラムをどの共有ライブラリともリンクさせない。 OUTPUT-FILE がライブラリの場合は静的ライブラリを作成するのみである。 -avoid-version どのような種類のバージョニングも行わない (バージョン情報は組み込まれず、シンボリックリンクも作られ ない)。 このオプションはバージョニングを必要とするプラットホーム上では働かない。 -dlopen FILE ホストプラットホーム上でネイティブな ダイナミックロードがサポートされていない場合や、 実行ファイル が -static や -all-static を 使ってリンクされる場合は、-dlpreopen FILE と同じ。 それ以外の場合は何 も影響を及ぼさない。 FILE が `実行ファイル自身' であった場合、 libtool は実行ファイルが -export-dynamic や -dlpreopen を使って自らを dlopen(3) できるかを確かめる。 -dlpreopen FILE FILE を出力プログラムにリンクし、そのシンボルを LT_PRELOADED_SYMBOLS に加える。 FILE が `出力プログラム自身' であった場合、 出力プログラム自身のシンボルが LT_PRELOADED_SYMBOLS に 加えられる。 -export-dynamic OUTPUT-FILE のシンボルを dlsym(3) を使って解決できるようにする。 -export-symbols FILE これをサポートしているプラットホーム上では、 リンカは FILE にリストされているシンボルのみをエクス ポートする。 FILE の名前は `.sym' で終っていなければならず、 1 行に 1 つのシンボルを含んでいなけれ ばならない。 デフォルトではすべてのシンボルがエクスポートされる。 -export-symbols-regex REGEX REGEX regex(7) にマッチするシンボルのみがエクスポートされる以外は -export-symbols と同じ。 -module ダイナミックロードできるライブラリを作成する。 モジュール名は `lib' で始まる必要はないが、 名前の 衝突を避けるため `libname' と `name' はパッケージの中で 同時に使用すべきではない。 -no-undefined OUTPUT-FILE が他のライブラリに依存していないことを宣言する。 他のライブラリに依存する共有ライブラ リを作れないプラットホームもある。 -release RELEASE ライブラリがパッケージのリリース RELEASE で作られたことを指定する。 これによって、ユーザーはどの バージョンが他のものより新しいかを 簡単に判断できる。 このフラグを使うと、パッケージの各リリースの いかなるペアの間にも バイナリ互換はなくなることに注意せよ。 バイナリ互換にしたい場合 は、-version-info フラグを使うこと。 -rpath LIBDIR OUTPUT-FILE がライブラリの場合、 最終的に LIBDIR にインストールされる。 -static OUTPUT-FILE がプログラムの場合、 アンインストールされた共有 libtool ライブラリはリンクしない。 OUTPUT-FILE がライブラリの場合、 静的ライブラリを作成するのみである。 -version-info CURRENT[:REVISION[:AGE]] OUTPUT-FILE が libtool ライブラリであるとき、 ライブラリをビルドするためにインターフェースバージョ ン情報 CURRENT, REVISION, AGE を使う。 パッケージのリリース情報を指定するために、 このオプションを 使ってはいけない。 むしろ -release フラグを参照すべきである。 実行モードオプション -dlopen FILE FILE を含んでいるディレクトリをライブラリパスに加える。
バージョニング
libtool は共有ライブラリ用に独自のバージョニングシステムを持っている。 このシステムを使いたい場合 は、-version-info オプションを 使わなければならない。 このオプションは CURRENT[:REVISION[:AGE]] という形 式の引数を受け付ける。 CURRENT インターフェースのバージョン。インターフェースとは "外側" の世界に見えるすべてのもので、 変数・関 数プロトタイプ・出力形式などである。 REVISION CURRENT からの相対値で与える実装のバージョン。 AGE このライブラリが実装している最新のインターフェースと 最古のインターフェースとの違い。 言い替える と、このライブラリは `CURRENT - AGE' から CURRENT までの範囲のすべてのインターフェース番号を実装し ていて、 このバージョンの範囲にあるライブラリに対して過去にリンクされた すべての実行ファイルは、こ のライブラリを使うことができる、 ということである。 REVISION と AGE が省略された場合のデフォルトは 0 である。 AGE は CURRENT インターフェース番号より小さいか 等しくなければならないことにも注意すること。 2 つのライブラリが同一の CURRENT 番号と AGE 番号であるとき、 ダイナミックリンカは大きい REVISION 番号のライブラリを選択する。 バージョニングのガイドライン: • 1. それぞれの libtool ライブラリについて `0:0:0' というバージョン情報から始めなさい。 • 2. バージョン情報を更新するのは ソフトウェアの公開リリースの直前だけにしなさい。 頻繁な更新は不必要で あり、現在のインターフェース番号が大きくなるのを 早くするだけである。 • 3. 前回の更新からライブラリのソースコードが すっかり変更されたなら、REVISION を増加させなさい (C:R:A が C:R+1:A になる)。 • 4. 前回の更新からインターフェースが 追加・削除・変更されたなら、CURRENT を増加させ、REVISION を 0 にし なさい。 • 5. 前回の公開リリースからインターフェースが 追加されたなら、AGE を増加させなさい。 • 6. 前回の公開リリースからインターフェースが 削除されたなら、AGE を 0 にしなさい。 パッケージバージョンをライブラリ名にエンコードしたい場合や、 libtool のバージョニングと衝突せずに 他の バージョニングシステムを使いたい場合は、-release を使うこと。 たとえば binutils-2.7.0.2 に付属する `libbfd.so.2.7.0.2' は libtool のバージョニングと明らかに衝突する。 `-release 2.7.0' を使えば `libbfd-2.7.0.so.0.0.0' で終ることができる。 異なる CURRENT バージョンのライブラリや 異なる -release のライブラリはバイナリ非互換であろう。
インターフェースの設計
良いライブラリインターフェースを書くには、 練習とライブラリが解決しようとしている問題に対する徹底的な理解 が必要である。 良いインターフェースを設計すれば、 頻繁に変更する必要はなく、ドキュメントを更新し続ける必 要もなく、 クライアントがライブラリの使い方を再び勉強し続ける必要もないだろう。 設計に対するガイドラインをいくつか示す: • 前もって計画を立てる エントリーポイントを頻繁に削除する必要がないように、 それぞれのインターフェースを最小にするようにしなさ い。 • インターフェースの変更を避ける もしインターフェースを再設計する必要があるならば、 クライアントが既に存在するコードを書き直す必要がないよ うに、 互換性のある関数も残しておくようにしなさい。 • 見えないデータタイプを使う クライアントがアクセスする必要のあるデータタイプの定義は少ない程良い。 可能ならば、関数がジェネリックポイ ンタ (内部データタイプにキャストすることが可能) を 受け付けるように設計しなさい。 クライアントに直接デー タを操作させるよりは、 アクセス関数を提供しなさい。 このようするとインターフェースを変更することなく デー タ構造を自由に変更できる。 • ヘッダファイルを使う それぞれのライブラリについて大域関数・大域変数をヘッダファイルに書いて ライブラリのソースファイルにインク ルードしておけば、 気づかずにインターフェースの変更をしてしまっても コンパイラが知らせてくれるだろう。 • 可能なときはいつでも静的 (もしくは等価なもの) を使う ライブラリに大域関数が少ないほど、ライブラリは柔軟に変更できる。 静的な関数・変数は、クライアントがアクセ スできないから インターフェースの変更とはならないので、好きなだけ変更することができる。
AUTOMAKE ルールの書き方
libtool ライブラリのサポートは、 LTLIBRARIES プライマリのもとに実装されている。 プログラムを libtool ライブラリにリンクするためには、 ライブラリ名を指定する program_LDADD 変数を使うこ と。 libtool に -static といったオプションを渡すためには program_LDFLAGS を使うと良い。 libtool ライブラリをビルドするには、 ライブラリ名を指定する lib_LTLIBRARIES を使うこと。 そして、たとえ ば、libtool に -version-info オプションを 渡すには lib_LDFLAGS を使うこと。 次のセクションに例がある。 作業をするためには、パッケージにいくつかの基本的なファイルを入れたり、 libtoolize を使う必要があるだろ う。 libtool スクリプトを直接インクルードしてはならない。 config.guess 標準システム名を推測しようとする。 config.sub 標準システム名を確認するサブルーチンスクリプト。 ltconfig 指示されたシステムについて libtool スクリプトを作成する。 ltmain.sh 基本的な libtool の機能を実装した一般的なスクリプト。
モジュールのダイナミックロード
libtool のダイナミックロード機能を使うためには、 configure.in のなかで AM_PROG_LIBTOOL より前に マクロ AC_LIBTOOL_DLOPEN を使わなければならない。 さもなければ、libtool はそのプラットホームには ダイナミック ロードのメカニズムがないと仮定して、 これをシミュレートしようとする。 このシミュレーション機能を使うため には、 実行ファイルをリンクするときに -dlopen と -dlreopen フラグを使い、 ダイナミックロードするオブジェ クトを宣言しなければならない。 libtool はオブジェクトファイルをリンクし、 以下のような実行ファイルのシン ボルテーブルを保持した データ構造を作成する。 struct lt_dlsymlist { const char *NAME; lt_ptr_t ADDRESS; } NAME には、"fprintf" のような、シンボル名のアスキー文字列が保持される。 ADDRESS は、&fprintf のような、 適切なオブジェクトへのジェネリックポインタである。 const lt_dlsymlist * lt_preloaded_symbols; この配列は実行ファイルにリンクされている プリロードされたシンボルを表す。 -dlpreloaded されたファイルのそ れぞれについて要素が存在し、 ファイル名 NAME と `0' というアドレス ADDRESS、 およびこのファイルからエクス ポートされたすべてのシンボルを保持する。 実行ファイル自身については、特別な名前 @PROGRAM@ が使われる。 最 後のエレメントは NAME と `0' という ADDRESS を持つ。 ダイナミックロードされるライブラリもしくは、 モジュールをダイナミックロードしようとする実行ファイルをリン クするときは、 -module フラグを指定するのを忘れないこと。 ダイナミックロードしようとしているライブラリの外部シンボルを、 実行ファイルが参照する必要がある場合は、実 行ファイルをリンクするときに -export-dynamic を使用すること。 ライブラリ名にバリエーションがあるので、 プログラムはどれがダイナミックロードするための 正しいファイルで あるのかを決定する必要がある。 直接的な方法は `.la' ファイルを調べて、 dlname='DLNAME' という行を探すことである。 この行はライブラリをダイナミックロードできない場合は空で、 そ うでない場合はライブラリの名前が入っている。
例
ソースファイル `foo.c', `bar.c' から `libbaz' とよばれるライブラリを作成し、 次に `a' という名前の実行 ファイルを作成するために `a.c' を `libbaz' と リンクしようといる。 ライブラリの作成 • コンパイルモード:Linux は共有ライブラリをサポートしているので、 libtool は 2 つのオブジェクトファイ ル、 一つは静的ライブラリ (`foo.lo')、 もう一つは共有ライブラリ (`foo.o') を作成する。 ソースファイル自身 へのリンクをコンパイラにやらせたくないので、 -c オプションは必須である。 lightside:~% libtool cc -c foo.c cc -c -fPIC -DPIC foo.c -o .libs/foo.lo cc -c foo.c >/dev/null 2>&1 lightside:~% libtool cc -c bar.c cc -c -fPIC -DPIC bar.c -o .libs/bar.lo cc -c bar.c >/dev/null 2>&1 • リンクモード、静的ライブラリのみをビルドする: 以前に作成された `.o' というオブジェクトファイルを指定し ている。 -o オプションは必須である。 lightside:~% libtool cc -o libbaz.a foo.o bar.o ar cru libbaz.a foo.o bar.o ranlib libbaz.a • リンクモード、静的ライブラリと共有ライブラリをビルドする: `.lo' というオブジェクトファイルを指定する。 必須オプションは、前と同じ -o と ライブラリのインストールされるディレクトリを指示する -rpath である。 ラ イブラリは `.libs' ディレクトリに作成される。 lightside:~% libtool cc -o libbaz.la foo.lo bar.lo \ -rpath /usr/local/lib cc -shared -Wl,-soname -Wl,libbaz.so.0 \ -o .libs/libbaz.so.0.0.0 foo.lo bar.lo (cd .libs && ln -s libbaz.so.0.0.0 libbaz.so.0) (cd .libs && ln -s libbaz.so.0.0.0 libbaz.so) ar cru .libs/libbaz.a foo.o bar.o ranlib .libs/libbaz.a creating libbaz.la (cd .libs && ln -s ../libbaz.la libbaz.la) • インストールモード:ライブラリを指定したパス (この場合は `/usr/local/lib') にインストールするために 必 要なコマンドを実行する。 このモードでは共有ライブラリ (`.so') と静的ライブラリ (`.a') を インストールする とともに、アンインストールと情報提供の目的で libtool ファイル (`.la') がインストールされる。 このモードはふつう特権ユーザーとして実行されるので、 -n または --dry-run オプションを 指定して結果を チェックしておくとよい。 lightside:/tmp% libtool -n install libbaz.la /usr/local/lib install .libs/libbaz.so.0.0.0 /usr/local/lib/libbaz.so.0.0.0 (cd /usr/local/lib && ln -s libbaz.so.0.0.0 libbaz.so.0) (cd /usr/local/lib && ln -s libbaz.so.0.0.0 libbaz.so) install libbaz.la /usr/local/lib/libbaz.la install .libs/libbaz.a /usr/local/lib/libbaz.a ranlib /usr/local/lib/libbaz.a chmod 644 /usr/local/lib/libbaz.a 実行ファイルの作成 最初に `a.c' をコンパイルする cc -c a.c ライブラリが既にインストールされている場合には、 普段のように続行することができる cc a.c -lbaz -L/usr/local/lib ライブラリがまだインストールされていない場合は、 実行ファイルのリンク・デバッグ・インストールに libtool を使用しなければならない (一度ライブラリがインストールされるまで、これはつづく)。 実際の実行ファイルはイ ンストールされるまで `.libs' 内にあり、 作業ディレクトリにある実行ファイルは単なるラッパーであることに注 意すること。 曖昧さを避けるため、絶対に -l と -L を使ってアンインストールされた 共有ライブラリにリンクしてはならない。 `.la' ファイルへのパスだけを指定すること。 以下の (`-lm') でわかるように、インストール済みのライブラリは 問題ではない。 lightside:~% libtool cc a.o libbaz.la -o a -lm cc a.o -Wl,--rpath -Wl,/usr/local/lib \ .libs/libbaz.so -o .libs/a -lm lightside:~% libtool gdb a [複雑なデバッグのセッションは省略] lightside:~% libtool install -c a /usr/local/bin/a install -c .libs/a /usr/local/bin/a Makefile.am の作成 • 最初に簡単な configure.in を作成し、 automake と libtool のためのマクロを忘れずに追加する。 AC_DEFUN(AM_INIT_AUTOMAKE) AC_INIT(a.c) AM_INIT_AUTOMAKE(a, 1.0) AC_PROG_CC AM_PROG_LIBTOOL AC_OUTPUT(Makefile) • 対応する Makefile.am # ライブラリのビルド lib_LTLIBRARIES=libbaz.la libbaz_la_SOURCES = foo.c bar.c libbaz_la_LDFLAGS = -version-info 0:0:0 bin_PROGRAMS = a a.debug # a.c と libbaz.la から a をビルド a_SOURCES = a.c a_LDADD = libbaz.la # 静的デバッグバージョンを作成 a_debug_SOURCES = a.c a_debug_LDADD = libbaz.la a_debug_LDFLAGS = -static • そして最後に実行する lightside:~% aclocal; libtoolize; automake --add-missing; autoconf lightside:~% ./configure; make
関連項目
libtoolize(1), libltdl(3)
注意
プログラムのバグについては <bug-libtool@gnu.org> へ報告してください。 この man ページは Ragnar Hojland Espinosa <ragnar@ragnar-hojland.com> が作成しました。