Previous: LTLIBOBJ, Up: A Shared Library


7.3.9 Libtoolの使用に関連する一般的な問題

7.3.9.1 required file `./ltmain.sh' not found

libtoolは,パッケージにlibtoolのサポートを行なうファイルをインストール するlibtoolizeと呼ばれるツールから生じます.このコマンドを実 行すると,ltmain.shがインストールされます.aclocalautomakeの前にそれを実行すべきです.

古いパッケージから新しいautotoolにアップグレードすると,古いバージョン のAutomakeはlibtoolizeと呼ばれるものを使用していたのでこの問 題に直面します.このため,古いビルドスクリプトではlibtoolize を呼び出しません.

Automake1.6から,libtoolizeの実行がAutomakeの仕事ではないと 決定しました.その代わり,その機能はautoreconfコマンドに渡さ れました(see Using autoreconf).いつ何を実行するのか覚えたくない場合, autoreconfコマンドだけを勉強して下さい.希望的には,既存の bootstrap.shautogen.shスクリプトをautoreconf の呼び出しに置換することで,将来においても同様の互換性の無い変更から自 由になれるでしょう.

7.3.9.2 libtoolで作成されたりされなかったりするオブジェクト

同じソースファイルが,libtoolライブラリのビルドと,libtoolではない他の ターゲット(プログラムだったり,他のライブラリだったりします)をビルドす るために使用されることもあります.

以下のMakefile.amを考えてみましょう.

     bin_PROGRAMS = prog
     prog_SOURCES = prog.c foo.c ...
     
     lib_LTLIBRARIES = libfoo.la
     libfoo_la_SOURCES = foo.c ...

(この平凡な状況では,prog_SOURCESにリストアップされている foo.cの代わりに,progを用いてlibfoo.laをリンクす ることを避けることで,問題を回避することが可能です.しかし,実際には proglibfoo.laは別々に保持したいと仮定します.)

技術的には,我々はprogに対してfoo.$(OBJEXT)をビルドし, libfoo.laに対してfoo.loをビルドべきだということを意味し ます.問題は,foo.loを作成する仮定で,libtoolが foo.$(OBJEXT)を削除(または置換)する可能性があるということです – これは避けられません.

このため,Automakeがこの状況を検出すると,以下のようなメッセージで文句 を言います.

     object `foo.$(OBJEXT)' created both with libtool and without

この問題を回避する方法は,これら二つのオブジェクトを確実に異なるベース 名にすることです.renamed objectsで説明されているように,ターゲッ トごとのフラグが使用されているとき,これは自動的に行なわれます.

     bin_PROGRAMS = prog
     prog_SOURCES = prog.c foo.c ...
     prog_CFLAGS = $(AM_CFLAGS)
     
     lib_LTLIBRARIES = libfoo.la
     libfoo_la_SOURCES = foo.c ...

prog_CFLAGS = $(AM_CFLAGS)の追加は,prog_CFLAGSが定義さ れているとき,AM_CFLAGSの代わりにそれを使用するので,ほとんど何 もしません.しかし,副作用として,prog.cfoo.cprog-prog.$(OBJEXT)prog-foo.$(OBJEXT)にコンパイルし, 問題を解決することになります.