| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
この章は，ユーザが混乱せずに共有ライブラリをインストールできるように，パッ ケージとlibtoolの統合方法を記述します．
| 5.1 libtoolに対する`Makefile'規則を書く | Writing `Makefile' rules for libtool. | |
| 5.2 libtoolと共にAutomakeを使用する | Automatically supporting libtool. | |
| 5.3 libtoolのコンフィグレーション | Configuring libtool for a host system. | |
| 5.4 パッケージにlibtoolを含める | What files to distribute with your package. | |
| 5.5 スタティックのみのライブラリ | Sometimes shared libraries are just a pain. |
libtoolは，完全にAutomake(see (automake)Top section `Introduction' in The Automake Manual)と統合されていて，それはAutomake version 1.2から開始さ れています．
通常の`Makefile'(や`Makefile.in')で，libtoolを使用したい場合は， 独自のものとなります．Automake 1.2を使用せず，パッケージにlibtoolの組み 込み方を知らない場合，以下の一つが必要になります．
Automake(バージョン1.2以降)を近くのGNUのミラーからダウンロードし，インス トールし，その使用を開始してください．
`Makefile'規則の手での書き方を学んでください．複雑なときもあります が，古いライブラリをコンパイルするための規則を書けるぐらいの知識がある場 合，libtoolライブラリに対する新しい規則の理解は可能でしょう(ヒント： libtool 配布物の`demo'サブディレクトリの`Makefile.in'を調べて ください… 特に，それがAutomakeによって`Makefile.am'から自動的 に生成されたことに注意してください)．
libtoolライブラリのサポートは，`LTLIBRARIES'プライマリの下で実装さ れています．
libtool配布物の`demo'サブディレクトリの，Automake `Makefile.am'からの例は，以下のようになっています．
最初に，プログラムをlibtoolライブラリとリンクするため， `program_LDADD'変数のみを使用してください．
bin_PROGRAMS = hell hell.debug # Build hell from main.c and libhello.la hell_SOURCES = main.c hell_LDADD = libhello.la # Create an easier-to-debug version of hell. hell_debug_SOURCES = main.c hell_debug_LDADD = libhello.la hell_debug_LDFLAGS = -static |
フラグ`-dlopen'と`-dlpreopen'(see section リンクモード)は， program_LDADD変数で，より適切になります．残念ながら，リリース1.4ま でのGNU automakeは，program_LDADD変数でこれらのフラグを受け入れな いため，以下で代用します．
それらをprogram_LDFLAGSに加え，program_DEPENDENCIESにライブ ラリをリストアップし，それらが属するこれらのフラグを受け入れるGNU automakeのリリースを待ってください．
フラグの回りを引用符で囲みます，しかし，program_DEPENDENCIESも設定 する必要があります．
program_LDADD = "-dlopen" libfoo.la program_DEPENDENCIES = libfoo.la |
`configure.in'の`AC_SUBST'で，変数DLOPENと DLPREOPENを設定し，`program_LDADD'での明確なフラグ `-dlopen'と`-dlpreopen'に対する置換物として，`@DLOPEN@' と`@DLPREOPEN@'を使用します．Automakeは，依存性から `AC_SUBST'された変数を捨てるので，`program_LDADD'のこれらのフ ラグを受け入れたとき，それは正確に期待したように動作します．
(インストールされていない共有libtoolライブラリとのリンクを避けるため `-static'を使用するような)`program'をリンクしている間，libtool に渡したいあらゆるフラグを詰め込むため，`program_LDFLAGS'変数を使用 することも可能です．
libtoolライブラリをビルドすることは，ほとんど冒険です… `-version-info'(see section ライブラリインターフェースのバージョン)オプションをlibtoolに渡すため， `libhello_la_LDFLAGS'を使用することに注意してください．
# Build a libtool library, libhello.la for installation in libdir. lib_LTLIBRARIES = libhello.la libhello_la_SOURCES = hello.c foo.c libhello_la_LDFLAGS = -version-info 3:12:1 |
`-rpath'オプションは，(noinst_LTLIBRARIESとしてリストアップ
されるライブラリ以外)Automakeにより自動的に渡されるので，指定する必要は
ありません．
詳細は，See Building a Shared Library: (automake)A Shared Library section `The Automake Manual' in The Automake Manual.
libtoolは，共有ライブラリを作成し適切なものにリンクするため，コンパイラセット とオペレーティングシステムの詳細な知識を必要とします．libtool配布物をイ ンストールするとき，システム特有のlibtoolスクリプトはバイナリディレクト リにインストールされます．
しかし，独自のパッケージとともにlibtoolを配布するとき (see section パッケージにlibtoolを含める)，パッケージをコンパイルするために使用されるコンパ イラセットとオペレーティングシステムを，常に知っているわけではありません．
このため，libtoolを使用する前にコンフィグレーションする必要があり
ます．この考えは，GNU configureスクリプトを使用するものに似ていま
す．configureは，システムの特徴に対しいくつものテストを行い，
`Makefiles'(と，おそらく`config.h'ヘッダファイル)を生成し，そ
の後，makeを実行しパケージをビルドすることが可能です．
libtoolは，インストーラのホストマシンに対するlibtoolスクリプトを生成する
ために，独自のテストをconfigureスクリプトに加えます．
5.3.1 AC_PROG_LIBTOOLマクロ | Configuring libtool in `configure.in'.
|
AC_PROG_LIBTOOLマクロ GNU Autoconf(やAutomake)を使用している場合，AC_PROG_LIBTOOLの呼び
出しを`configure.in'に加える必要があります．このマクロは，
生成されたlibtoolスクリプトがホストの特徴を理解できるようにするため，
多くの新しいテストをconfigureスクリプトに加えます．
`--enable-shared'と`--disable-shared'のconfigureフラグ
に対するサポートを加えます．(5) AM_PROG_LIBTOOLは，このマクロに対する古い名前で，しばらくは
サポートされますが，やめた方がいいでしょう．
デフォルトで，このマクロは，利用可能な場合は共有ライブラリを開始し，共有
ライブラリと衝突しない場合はスタティックライブラリも可能とします．これら
のデフォルトは，AC_DISABLE_SHAREDやAC_DISABLE_STATICマクロ
のどちらかで修正可能です．
# Turn off shared libraries during beta-testing, since they # make the build process take too long. AC_DISABLE_SHARED AC_PROG_LIBTOOL |
ユーザは，パッケージ名を元にビルドされる，共有またはスタティックライブラ
リを選択するため，`--enable-shared'と`--enable-static'コンフィ
グレーションフラグで指定を修正できます．例えば，共有する`bfd'と
`gdb'ライブラリをビルドし，`libg++'を共有にしないため，以下の
configureスクリプトの実行で，３つのことのすべて可能となります．
trick$ ./configure --enable-shared=bfd,gdb |
一般的に，`--enable-shared=pkgs'の指定は，カンマで分けられた pkgsリストに名前があるすべてのパッケージを`--enable-shared'で， それ以外のすべてのパッケージを`--disable-shared'でコンフィグレーショ ンすること同じです．`--enable-static=pkgs'フラグは，同様に動 作しますが，その場合は`--enable-static'と`--disable-static'を 使用します．同様に，`--enable-fast-install=pkgs'フラグは適用 され，それは，`--enable-fast-install'と `--disable-fast-install'を使用します．
パッケージ名`default'は，PACKAGE環境変数に名前が設定されてい
ない，あらゆるパッケージに一致します．
このマクロは，シェル変数LIBTOOL_DEPSも設定し，それで，libtoolスク リプトが時代遅れになった場合の自動的な更新に使用できるようになります．そ うするために`configure.in'に以下を加えてください．
AC_PROG_LIBTOOL AC_SUBST(LIBTOOL_DEPS) |
そして，`Makefile.in'や`Makefile.am'に，以下を加えてください．
LIBTOOL_DEPS = @LIBTOOL_DEPS@
libtool: $(LIBTOOL_DEPS)
$(SHELL) ./config.status --recheck
|
GNU automakeを使用してる場合，automakeが面倒をみるので，指示の省略が可能 です．`libtool'での依存性を明確に作成する必要があります．
dlopenサポートの調査を可能にします．パッケージで`-dlopen'と
`-dlpreopen'フラグを使用する場合，このマクロ使用すべきで，そうしな
い場合，libtoolはシステムがdlopenをサポートしていないと仮定します．マク
ロはAC_PROG_LIBTOOLの前で呼び出す必要があります．
このマクロは，win32プラットフォームでクリーンなdllをビルドするために移植
する場合，使用する必要があります．通常，これは，あらゆるライブラリデータ
項目を__declspec(dllexport)でエクスポートし，
__declspec(dllimport)でインポートすることを意味します．このマクロ
が使用されていない場合，libtoolはパッケージライブラリがクリーンなdllでは
なく，win32ホストでのスタティックライブラリのみをビルドすると仮定します．
このマクロはAC_PROG_LIBTOOLの前で呼び出す必要があり，パッ
ケージのMakefileでのリンクモードでの準備として，libtoolに
`-no-undefined'を渡させる必要があります．通常，`-no-undefined'
を渡す場合，すべてのライブラリシンボルが，リンク時には本当に定
義されていることを確かめる必要があります！
AC_PROG_LIBTOOLのデフォルトの動作を，高速インストールに対する最適
化を不可能にするよう変更します．ユーザはこのデフォルトを，プラットフォー
ムのサポートに依存して，`--enable-fast-install'を指定することで優先
させることができます．
AC_PROG_LIBTOOLのデフォルトの動作を，共有ライブラリを利用不可能に
変更します．ユーザはこのデフォルトを，`--enable-shared'を指定するこ
とで優先させることができます．
AC_PROG_LIBTOOLのデフォルトの動作を，スタティックライブラリを利用
不可能に変更します．ユーザはこのデフォルトを，`--enable-static'を指
定することで優先させることができます．
AC_PROG_LIBTOOL内のテストは，以下の環境変数も認識します．
生成されたlibtoolが使用するCコンパイラです．これが設定されていな
い場合，AC_PROG_LIBTOOLはgccやccを探します．
標準的なオブジェクトファイルを生成するために使用するコンパイラフラグです．
これが設定されていない場合，AC_PROG_LIBTOOLはそのようなフラグを全
く使用しません．それは，AC_PROG_LIBTOOLがテストを実行する方法にの
み効果があり，生成されたlibtoolには効果はありません．
Cプリプロセッサフラグです．これが設定されていない場合，
AC_PROG_LIBTOOLはそのようなフラグを全く使用しません．それは，
AC_PROG_LIBTOOLがテストを実行する方法にのみ効果があり，生成された
libtoolには効果はありません．
(生成されたlibtoolが要求する場合は)システムリンカです．これが設定
されていない場合，AC_PROG_LIBTOOLは，CCで使用されるリンカが
何かを判別しようとします．
プログラムをリンクするとき，libtoolが使用するフラグです．これが設
定されていない場合，AC_PROG_LIBTOOLはそのようなフラグを全く使用し
ません．それは，AC_PROG_LIBTOOLがテストを実行する方法にのみ効果が
あり，生成されたlibtoolには効果はありません．
プログラムのリンクとき，AC_PROG_LIBTOOLが使用するライブラリです．
これが設定されていない場合，AC_PROG_LIBTOOLはそのようなフラグを使
用しません．それはAC_PROG_LIBTOOLが実行するテストにのみに効果があ
り，生成されたlibtoolには効果はありません．
使用するプログラムで，nmの調査ではありません．
使用するプログラムで，ranlibの調査ではありません．
プログラムのリンクを作成するコマンドで，可能な場合はソフトリンク，それ以
外ではハードリンクです．この変数が設定されていない場合，
AC_PROG_LIBTOOLは適切なプログラムを調査します．
使用するプログラムで，dlltoolの調査ではありません．
Cygwin/MS-Windowsでのみ意味があります．
使用するプログラムで，objdumpの調査ではありません．
Cygwin/MS-Windowsでのみ意味があります．
使用するプログラムで，asの調査ではありません．しばらくは，
Cygwin/MS-Windows でのみ使用されます．
libtoolizeプログラムを呼び出すとき(see section libtoolizeの呼び出し)，
それはAC_PROG_LIBTOOLの定義が見つかる場所を伝えます．Automakeを使
用している場合，aclocalプログラムは自動的に，configureスク
リプトにAC_PROG_LIBTOOLサポートをconfigureスクリプトに加え
ます．
それにもかかわらず，`acinclude.m4'に`libtool.m4'のコピーを含め
ることは賢明で，そのため，`aclocal.m4'と`configure'がとある理
由で再びビルドされた場合も，適切なlibtoolマクロが使用されます．代わりに，
ユーザが`libtool.m4'の互換バージョンをインストールしていて，
aclocalにアクセス可能なことを期待します．これは，バージョンが一致
しない場合，不運なエラーを導くかもしれません．
libtoolを使用するため，パッケージに以下のファイルを含める必要があります．
標準的なシステム名の判別を試みます．
標準的なシステム名を評価する，サブルーチンスクリプトです．
基本的なlibtool機能を実装する一般的なスクリプトです．
libtoolスクリプト自身はパッケージに含まれないことに注意してください． See section libtoolのコンフィグレーション.
手動でこれらのファイルをパッケージにコピーするより，libtoolizeプ
ログラムを使用した方がよいでしょう．
5.4.1 libtoolizeの呼び出し | libtoolize command line options.
| |
| 5.4.2 Autoconfの`.o'マクロ | Autoconf macros that set object file names. |
libtoolizeの呼び出し libtoolizeプログラムは，libtoolサポートをパッケージに追加する標準
的な方法を提供します．将来は，より良い調査の使用法や，より簡単にlibtool
を作成する特徴を実装するかもしれません．
libtoolizeプログラムは以下の構文です．
libtoolize [option]… |
そして，以下のオプションを受け入れます．
静かに動作し，libtoolがサポートされているAutomakeを仮定します．
`libtoolize --automake'は，AC_PROG_LIBTOOLが
`configure.in'にあるとき，Automakeがlibtoolファイルをパッケージに追
加するために使用します．
libtoolデータディレクトリから，シンボリックリンクを作成するのではなく， ファイルをコピーします．
シェルスクリプトの実行の追跡を，標準出力にダンプします．これは大量の出力
を生成するため，less(やmore)にパイプしたり，ファイルにリダ
イレクトしたいかもしれません．
ファイルシステムを変更するコマンドは実行せず，それらを出力するだけです．
既存のlibtoolのファイルを置換します．デフォルトで，libtoolizeは既
存のファイルを上書きしません．
へルプメッセージを出力し終了します．
パッケージのサブディレクトリに，libltdlをインストールします．
ファイルlibltdl.tar.gzをパッケージに追加します．
libtoolizeのバージョン情報を出力し終了します．
libtoolizeが，パッケージの`configure.in'で，明確な
AC_CONFIG_AUX_DIRの呼び出しを検出した場合(see (autoconf)Input section `The Autoconf Manual' in The Autoconf Manual)，指定されたディレクトリ
にファイルを配置します．
libtoolizeは，パッケージにlibtoolサポートを加えるヒントも同様に表
示します．
utoconfパッケージは，テストを実行するいくつかのマクロをもたらし，それは， オブジェクトファイル名に対応して変数を設定します．libtoolオブジェクトに 対応する名前を使用する必要があるときもあります．
ここにlibtoolオブジェクトがリストアップする変数名があります．
AC_FUNC_ALLOCAで置換されます(see Particular Function Checks: (autoconf)Particular Functions section `The Autoconf Manual' in The Autoconf Manual)．空，または`alloca.lo'を含みます．
AC_REPLACE_FUNCS(see Generic Function Checks: (autoconf)Generic Functions section `The Autoconf Manual' in The Autoconf Manual)とその他の関
数で置換されます．
残念ながら，安定版のリリースのAutoconf(これを書いている時期は，2.13)は，
libtoolでこれらの変数を提供する方法が全くありません．そのため，それに依
存して，パッケージの`configure.in'でAC_OUTPUTを呼び出す前に，
以下のコードの実装を使用してください．
LTLIBOBJS=`echo "$LIBOBJS" | sed 's/\.[^.]* /.lo /g;s/\.[^.]*$/.lo/'` AC_SUBST(LTLIBOBJS) LTALLOCA=`echo "$ALLOCA" | sed 's/\.[^.]* /.lo /g;s/\.[^.]*$/.lo/'` AC_SUBST(LTALLOCA) AC_OUTPUT(…) |
パッケージを開発しているとき，パッケージを`--disable-shared'フラグ
でコンフィグレーションしたり，AC_DISABLE_SHARED Autoconfマクロ
(see section The AC_PROG_LIBTOOL macro)を使用して，
AC_PROG_LIBTOOLのデフォルトに優先することに価値があることもよくあ
ります．これは，libtoolが共有ライブラリをビルドすることを避け，それには，
いくつかの利点があります．
2回目のコンパイルを速くし，開発サイクルを高速にします．
共有ライブラリによって加えられる複雑さの詳細が不要なので，デバッグがより 簡単になります．
スタティックのみのプラットフォームでのlibtoolの動作方法が分かります．
パッケージの`README'に，他の開発者に`--disable-shared'で時間を 稼げることを知らせるため，ちょっとした注意を書きたいかもしれません．以下 の例の注意は，GIMP(6) 配布物の`README'から持ってきました．
The GIMP uses GNU Libtool in order to build shared libraries on a variety of systems. While this is very nice for making usable binaries, it can be a pain when trying to debug a program. For that reason, compilation of shared libraries can be turned off by specifying the `--disable-shared' option to `configure'. |
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated by Akihiro Sagawa on June, 15 2005 using texi2html 1.70.