[ << ] | [ >> ] | [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'を
configure
へのフラグとして変更を指定してもかまいません.例え
ば,共有する`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サポートを加えるヒントも同様に
表示します.
Autoconfパッケージは,テストを実行するいくつかのマクロをもたらし,それ は,オブジェクトファイル名に対応して変数を設定します.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が共有ライブラリをビルドすることを避け,
それには,いくつかの利点があります.
二回目のコンパイルを速くし,開発サイクルを高速にします.
共有ライブラリによって加えられる複雑さの詳細が不要なので,デバッグがよ り簡単になります.
スタティックのみのプラットフォームでの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.