問題タブ [libtool]

誰かがこのようなものを見たことがありますか？

autotoolsを使用してプロジェクトでmakeを実行すると、常にすべてが再構築されます。make -dを指定して実行すると、makeがfoo.loファイルを検索し、ファイルが見つからないため、常にfoo.cを再コンパイルすることが示されます。

builddir！=srcdirに関連しているようです。もちろん、.loファイルはbuilddirにあります。しかし、どうやらmakeまたはlibtoolは、どこか別の場所でそれらを期待しているようです。

デバッグ出力は次のようになります。

前提条件/path/to/srcdir/foo.h' is older than targetのfoo.lo'。/path/to/builddir/.deps/foo.Plo:1ターゲット`foo.lo'を作り直す必要があります。

更新問題の原因はAC_PROG_LIBTOOLのようです。ドキュメントによると、top_builddirという変数がbuilddirectoryに設定されることを想定しています。それを設定する標準的な方法は何ですか？このためのautoconfマクロはありますか？

私はいくつかのC++クラスを持っており、autotoolsとlibtoolを使用してそれらを共有ライブラリにコンパイルしたいと思います。これらは私のconfigure.acファイルとMakefile.amファイルです。

configure.ac：

Makefile.am：

Libtoolは静的ライブラリのみを作成しますが、configure --disable-static --enable-sharedを呼び出して、共有オブジェクトを作成するようにスクリプトに明示的に指示します。私のファイルの何が問題になっていますか？

- - 編集 - -

libtoolからのリンクコマンド：

ここに投稿された指示に従ってください：http：//stackoverflow.com/questions/9450394/how-to-install-gcc-from-scratch-with-gmp-mpfr-mpc-elf

GMP、MPFR、およびELFを問題なくインストールしましたが、MPCをインストールしている間

次のエラーが発生します。

それを修正する方法はありますか？間違ったディレクトリを探しているようです。

編集：ジョンによってリンクされた指示に従った後、それは3時間後にエラーになりました

make [5]：* [gnu / java / nio/charset.lo]エラー1make[5]：ディレクトリ/apps/ddechev/gcc47/x86_64-unknown-linux-gnu/32/libjava' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory/apps/ddechev/gcc47/x86_64-unknown-linux-gnu/32/libjava'make [3]を離れています： * [multi-do]エラー1make[3]：ディレクトリ/apps/ddechev/gcc47/x86_64-unknown-linux-gnu/libjava' make[2]: *** [all-multi] Error 2 make[2]: Leaving directory/ apps / ddechev / gcc47 / x86_64-unknown-linux-gnu / libjava'make [1]を離れます：* [all-target-libjava]エラー2make [1 ]：ディレクトリを離れる

なぜですか？

すべての API ドキュメントが doxygen を使用して行われるライブラリ (libtools を使用) を作成しています。

生成された doxygen ドキュメントのインストールを autotools に統合する簡単な方法があるかどうか疑問に思っています。

ドキュメントの作成は簡単だと思います。しかし、doxygen を実行したら、生成された (たとえば) .html ファイルを $(htmldir) に取得する適切な方法は何ですか?

問題は、doxygen が作成しようとしているファイルがわからない (知りたいとも思わない) ことのようです。

「html_DATA=html/*.*」のようなものは悪い考えだと思います

libtoolを使用して libfoo.a と libfoo.so の 2 つのオブジェクトにコンパイルされたライブラリ ( libfoo ) があります。

libtoolも使用して、すべての libfoo のコードを含む単一の共有ライブラリ (libbar.so) になる別のライブラリ ( libbar ) を作成する必要があります。

これを行うには、libbar が libfoo.so ではなく libfoo.aにリンクするように強制する必要があります。

私はautotools環境にいるので、標準のconfigure.inまたはMakefile.amルールを使用してこれを解決する必要があります。

configure.in のように、いくつかのことを試しました:

これにより、常にリンク行に -Wl フラグが付きます。しかし -lfoo は消えて、先頭に絶対パス形式 ( /opt/foo/lib/libfoo.so ) で配置されています。

私も試しました：

または Makefile.am で:

と

etc etc (非常に多くのバリエーションがあります!)

しかし、これを単独で解決するには、Autotools/Libtool について十分な知識がないことは間違いないと思います。私はそれについてネット上で情報を見つけることができませんでした.常にわずかに異なる問題です.

プロトコル分析を理解するためにWiresharkのソースコードを表示しようとしていますが、を使用するときに+gdb ./wiresharkを押してブレークポイントを設定し、次に入力すると、プロセスが停止することがわかりました。GDBのデバッグを可能にするためにlibtoolが何をするのか知りたいです。CtrlCC

すでに読んだman libtoolことがありますが、libtoolはあらゆる種類のツールである.aか.o、シンプルなインターフェイスで簡単に使用できるツールであると書かれていますが、libtoolで何が重要かわかりませんgdb wireshark。

プラグインを追加する機能を実装したい C++ のプロジェクトに取り組んでいます。コンパイル プロセスは Autotools によって処理されます。ファイル構造を正しく設定することができ、メイン プロジェクトとプラグインの両方がコンパイルされましたが、実行時に何らかの理由でプラグインが省略されましたmake install。プラグインを個別にコンパイルしてインストールすると、正常に動作します。ここに何か足りないのですか、それともトップ フォルダからプラグインがインストールされないのはなぜですか?

configure.ac

Makefile.am

plugins/defaultReport/configure.ac

plugins/defaultReport/Makefile.am

autoconf、automake、libtoolでビルドされた新しいc++プロジェクトがあります。機能は、サポートライブラリとユーザーバイナリに分けられます。unittestsこれらのライブラリにリンクし、一度にビルドおよび実行されるが、インストールされていないバイナリのセットもありmake checkます。

プロジェクトは新しいと言いました。私は実際、インストールする必要のある最初のライブラリを抽出することに取り掛かっています。これまで、（少量の）記述されたコードは直接にコンパイルされていましたunittests。

私が試したMakefile.amスニペットは次のようになります。

で、私はこれmake checkを取得します：

欠落しているライブラリは、まさに私がコンパイルしようとしているライブラリであることに注意してください。

（ライブラリはそうではありませんlibfooが、このスタブライブラリで同じエラーを再現できます。上記のMakefile.amおよびエラー行はリテラルであり、編集されていません。）

automake行をに変更すると

コンパイルは次のようになります。

..そしてすべてが正常に動作します（私のライブラリがインストールされていないことを除いて、にありcheck_ます。）

コマンドラインの唯一の違いは、2番目の引数のいくつかの追加の引数であることに注意してください。

... -Wl、-rpath / usr / local / lib -o libfoo.la -rpath / usr / local / lib foo.lo-lboost_thread-mt..。

この新しい議論がそこにあるべきではないかどうかはわかりませんが、それが問題を引き起こしているように見えます。誰かが私が欠けているものを知っていますか？

詳細：

• osx lionでは、これは正常に機能します（コマンドラインは異なります）。このエラーは、ubuntu 12.04、場合によっては他のLinuxで発生します。
• noinst_LTLIBRARIESのEXTRA_LTLIBRARIESように機能check_LTLIBRARIESします：余分な引数はなく、リンクします。libtoolの「コンビニエンス」ライブラリは、特にこれらの引数がないライブラリのようです。
• automake 1.11.1
• autoconf 2.68
• libtool 2.4

編集

（手動で）-Wl,-rpath /usr/local/lib引数から削除すると、問題も修正されます。

GNU Autotools を使用して ZipArchive を使用する共有ライブラリを構築したいのですが、次の問題が発生しています。

スタティック ライブラリをビルドした場合、または ZipArchive の共有ライブラリを使用した場合は機能しますが、問題は、ZipArchive ソース コードに付属する makefile がスタティック ライブラリのみをビルドすることです。

Libtool に静的ライブラリとのリンクを強制するにはどうすればよいですか?

aaに依存するプログラムがlibbbありますlibcc。

libbのMakefile.amに追加しました

aaのMakefileに追加しました

これは、デフォルトの場合にうまく機能します。

しかし、静的リンクが必要だったので、すべての構成をで実行しました--disable-shared。
残念ながら、コンパイルaa時に次のようになりました。

libb_source.c：libcc_symbolへの未定義の参照

何が欠けているのかアイデアはありますか？

更新：クロスコンパイルしてstagingdirを使用している場合は、このような依存関係を指定することを考えないでください。