| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
この章は，ユーザが混乱せずに共有ライブラリをインストールできるように， パッケージとlibtoolの統合方法を記述します．
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
libtoolは，完全にAutomake(see 節 `Introduction' in
通常の`Makefile'(や`Makefile.in')で，libtoolを使用したい場合 は，独自のものとなります．Automake 1.2を使用せず，パッケージにlibtool の組み込み方を知らない場合，以下の一つが必要になります．
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
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 節 4.2 リンクモード)は， program_LDADD変数で，より適切になります．残念ながら，リリース1.4 までのGNU automakeは，program_LDADD変数でこれらのフラグを受け入 れないため，以下で代用します．
program_LDADD = "-dlopen" libfoo.la program_DEPENDENCIES = libfoo.la |
(インストールされていない共有libtoolライブラリとのリンクを避けるため `-static'を使用するような)`program'をリンクしている間， libtool に渡したいあらゆるフラグを詰め込むため，`program_LDFLAGS' 変数を使用することも可能です．
libtoolライブラリをビルドすることは，ほとんど冒険です... `-version-info'(see 節 6. ライブラリインターフェースのバージョン)オプションを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 節 `The Automake Manual' in
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
libtoolは，共有ライブラリを作成し適切なものにリンクするため，コンパイ ラセットとオペレーティングシステムの詳細な知識を必要とします．libtool 配布物をインストールするとき，システム特有のlibtoolスクリプトはバイナ リディレクトリにインストールされます．
しかし，独自のパッケージとともにlibtoolを配布するとき (see 節 5.4 パッケージにlibtoolを含める)，パッケージをコンパイルするために使用されるコン パイラセットとオペレーティングシステムを，常に知っているわけではありま せん．
このため，libtoolを使用する前にコンフィグレーションする必要があ ります．この考えは，GNU configureスクリプトを使用するものに似て います．configureは，システムの特徴に対しいくつものテストを行い， `Makefiles'(と，おそらく`config.h'ヘッダファイル)を生成し， その後，makeを実行しパケージをビルドすることが可能です．
libtoolは，インストーラのホストマシンに対するlibtoolスクリプトを生成す るために，独自のテストをconfigureスクリプトに加えます．
5.3.1 AC_PROG_LIBTOOLマクロConfiguring libtoolin `configure.in'.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
AC_PROG_LIBTOOLマクロAC_PROG_LIBTOOLマクロ"へのコメント(無し)
GNU Autoconf(やAutomake)を使用している場合，AC_PROG_LIBTOOLの呼 び出しを`configure.in'に加える必要があります．このマクロは，生成 されたlibtoolスクリプトがホストの特徴を理解できるようにするため，多く の新しいテストをconfigureスクリプトに加えます．
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'での依存性を明確に作成する必要があります．
AC_PROG_LIBTOOLの前で呼び出す必要があります．__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には効果はありません．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 節 5.4.1 libtoolizeの呼び出し)， それはAC_PROG_LIBTOOLの定義が見つかる場所を伝えます．Automakeを 使用している場合，aclocalプログラムは自動的に，configure スクリプトにAC_PROG_LIBTOOLサポートをconfigureスクリプト に加えます．
それにもかかわらず，`acinclude.m4'に`libtool.m4'のコピーを含 めることは賢明で，そのため，`aclocal.m4'と`configure'がなん らかの理由で再びビルドされた場合も，適切なlibtoolマクロが使用されます． 代わりに，ユーザが`libtool.m4'の互換バージョンをインストールして いて，aclocalにアクセス可能なことを期待します．これは，バージョ ンが一致しない場合，不運なエラーを導くかもしれません．
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
libtoolを使用するため，パッケージに以下のファイルを含める必要があります．
libtoolスクリプト自身はパッケージに含まれないことに注意してください． See 節 5.3 libtoolのコンフィグレーション.
手動でこれらのファイルをパッケージにコピーするより，libtoolize プログラムを使用した方がよいでしょう．
5.4.1 libtoolizeの呼び出しlibtoolizecommand line options.5.4.2 Autoconfの`.o'マクロ Autoconf macros that set object file names.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
libtoolizeの呼び出しlibtoolizeの呼び出し"へのコメント(無し)
libtoolizeプログラムは，libtoolサポートをパッケージに追加する標 準的な方法を提供します．将来は，より良い調査の使用法や，より簡単に libtoolを作成する機能を実装するかもしれません．
libtoolizeプログラムは以下の構文です．
libtoolize [option]... |
そして，以下のオプションを受け入れます．
`libtoolize --automake'は，AC_PROG_LIBTOOLが `configure.in'にあるとき，Automakeがlibtoolファイルをパッケージに 追加するために使用します．
less(やmore)にパイプしたり，ファイルに リダイレクトしたいかもしれません．
libtoolizeは 既存のファイルを上書きしません．
libtoolizeのバージョン情報を出力し終了します． libtoolizeが，パッケージの`configure.in'で，明確な AC_CONFIG_AUX_DIRの呼び出しを検出した場合(see 節 `The Autoconf Manual' in
libtoolizeは，パッケージにlibtoolサポートを加えるヒントも同様に 表示します．
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
Autoconfパッケージは，テストを実行するいくつかのマクロをもたらし，それ は，オブジェクトファイル名に対応して変数を設定します．libtoolオブジェ クトに対応する名前を使用する必要があるときもあります．
libtoolオブジェクトがリストアップする変数名には以下のものがあります．
AC_FUNC_ALLOCAで置換されます(see 節 `The Autoconf Manual' in
AC_REPLACE_FUNCS(see 節 `The Autoconf Manual' in
残念ながら，安定版のリリースの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(...) |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |
パッケージを開発しているとき，パッケージを`--disable-shared'フラ グでコンフィグレーションしたり，AC_DISABLE_SHAREDAutoconfマクロ (see 節 The AC_PROG_LIBTOOL macro)を使用し て，AC_PROG_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'. |
| [ << ] | [ >> ] | [表紙] | [目次] | [索引] | [検索] [上端 / 下端] [?] |