問題タブ [libtool]

libtoolを使用すると、それがより複雑になるだけのようです。なぜgccに固執しないのですか？

gdbを使用してlibtoolでビルドされたパッケージのテストプログラムをデバッグしようとすると、奇妙な問題が発生します。実行libtool --mode=execute gdb .libs/libfoo.soして関数のソースをリストするように依頼するとlist Bar::Baz、期待どおりにソースコードが取得されます。を実行するlibtool --mode=execute gdb binaryと、侵入しBar::Baz()てスタックトレースでその引数を確認できますが、次のようにソースファイルまたは行番号を取得できません。

同様にlist Bar::Baz、実行可能ファイルをデバッグしようとすると、次のようになります。

バイナリがとリンクされていることを確認し、-gその機能を一覧表示できるmainので、デバッグ情報の一部が存在することがわかります。

と言うとinfo sources、ライブラリが構築されているファイルの完全なリストと、正しい絶対パスが表示されます。と言うとinfo shared、オブジェクトファイルへの正しいパスがリストさYesれ、Syms列にが表示されます。

何がうまくいかない可能性があり、それを修正する方法についてのさらなるアイデアはありますか？

編集1：誤っobjdump -gて、問題のあるライブラリを実行し、次の出力を取得しました。

objdump -h（私が実行しようとしたもの）にはたくさんの.debug_*セクションがリストされているので、これは驚くべきことです。objdumpマニュアルreadelf -wも同様に示唆しており、それは膨大な情報の山を印刷しているようです。ただし、実際に何が提供されるかを確認する必要があります。

編集2：それで、readelf -wいくつかの悟りを生み出しました。何らかの理由で、共有オブジェクトファイルには、リンクされているオブジェクトの大部分 からのデバッグ情報が含まれていないようです。Makefilesに基づいて、オブジェクトを共有ライブラリに実際に収集するコマンドが渡されず、情報が適切に伝播されない可能性があります。面白いことに、これは（現在のx86に対して）x86_64の同じコンパイラバージョンを含む、他のすべての構成で機能します（完全なデバッグ情報があります）。-g

編集3：実際には、LDFLAGSに-gが追加された変更されたMakefileを使用して完全に再構築されましたが、違いはありませんでした。今、私は元気で本当に困惑しています。

Linux マシンで ImageMagick をクロスコンパイルしようとしています。ツールチェーンに付属する libstdc++.a は、fPIC でコンパイルされていません。代わりにsoファイルを使用したいと思います。ただし、libtool は libstdc++.a を (アーカイブ全体として) リンクし続け、再配置エラーが発生します。他のライブラリでも同じ問題が発生しました。何か案は？

--as-neededAutomakeを使用して共有ライブラリをリンクするにはどうすればよいですか？にフラグを追加しようとするとLDFLAGS、次のようにlibtool呼び出されます。

その結果、次のようにGCCが呼び出されます。

しかし、それは間違った順序です。

• Libtoolでこれを行う方法はありますか？

• または、Automakeを使用してLibtoolを使用せずに共有ライブラリを構築するための優れた方法はありますか？（私は過去に他のさまざまな理由でLibtoolに不満を感じていました...）

Debianの人々もこの問題に遭遇したようです（バグレポート）が、システムを台無しにするのではなく、プロジェクトのためにこれを修正できるようにしたいと思います（修正を誤解しない限り）。

.la および .a ライブラリも --prefix パスにインストールせずに、autotools/libtool を使用して .so モジュールをビルドおよびインストールする方法は?

現在、私は次の Makefile.am を使用しています:

動作しますが、libCurlDownloader.so に加えて、望ましくない libCurlDownloader.la と libCurlDownloader.a もインストールします。

更新 #1

いずれかを使用して、.a を生成しないようにすることができます。

また

configure.ac で

しかし、.so がインストールされている間に .la がインストール --prefix にインストールされないようにする方法は依然として問題です。

アップデート #2

--prefix を使用して、インストールから .la ファイルを削除することができます。

実行時に特定のモジュール (共有ライブラリ) をロードするクロスプラットフォーム プログラムを c++ で作成しようとしています。これを行うために、Poco C++ Librariesの ClassLoader を使用しています。autoconf、automake、libtool を使用してコンパイル チェーンを作成しました。これは Linux 環境では問題になりませんが、Windows では問題が発生します。Makefile を利用できるようにコンパイルするときに、MinGW と MSYS を使用しています。ClassLoader は、Windows 固有の LoadLibrary() 関数を使用してモジュールをロードします。つまり、モジュールを DLL としてコンパイルする必要があります。

ライブラリにコンパイルするクラスは、メイン アプリケーション内の別のクラスを継承します。その後、make を実行しようとすると、未定義の参照について多くのエラーが表示され、共有ライブラリの構築が拒否されます。これは名前のマングリングが原因だと思います。それとも、ライブラリの外でクラスを継承できないからですか? (そのクラスはライブラリのソースに含まれていませんが、ヘッダー ファイルは見つかります)

MinGW + MSYS の下でコンパイルすることを主張するが、それでも LoadLibrary() を使用することがどれだけの問題をもたらすかはよくわかりません。これの経験がある人はいますか？

ロード可能なモジュールとしてコンパイルされた、つまりlibtoolの-moduleフラグにリンクされたいくつかのライブラリを使用したプロジェクトを手元に持っています。これらのライブラリには、必要なすべての関数がそれ自体またはその依存関係に含まれている必要があります。つまり、プログラムのモジュール インターフェイスのすべての関数を単に呼び出す単純な main() 関数とリンクすると、完全なプログラムが生成されるはずです。

以前に不完全で使用できないモジュールに問題があったため、main() だけを含み、モジュールに対してリンクされているいくつかの単純なチェック プログラムがあります。関数が欠落している場合、リンカーは適切な警告を発するので、すべて問題ありません。ただし、libtool から 1 つの警告が表示されます。

この警告の目的と意図は理解していますが (プログラムを でビルドされたライブラリにリンクしないでください-module)、その重大度については理解していません。それが私の質問です:

この警告はどの程度深刻ですか? 私がコンパイルしているプラ​​ットフォーム (i386/x86_64 Linux および MinGW) でこれが機能するのは幸運でしょうか?それとも、この警告は、私が安全に無視できるあいまいなバックウッド プラットフォームに関連しているだけなのでしょうか?

たとえば、Debian Lenny（libc、postgres、oracle、その他のlibs）と互換性のあるアプリケーションを別のDebian/Ubuntuリリースで構築したいと思います。これは可能ですか？もしそうなら、どこでそれを行う方法を読むことができますか？

Ubuntu 11.10 サーバーに PCRE をインストールしようとしています。「make」コマンドを実行すると、非常に長い出力が得られ、常にこのエラーで終了します。

「構成」を実行しました。何か案は？

Autotools: A Practioner 's Guide to GNU Autoconf, Automake, and Libtoolの第 6 章 (libtool を使用したライブラリの構築) では、ライブラリのリンクの例が示されています。

この例では、ライブラリlibjupiter.soが別のライブラリにリンクされていますlibjupcommon.a。libjupiter.soPIC が必要なため、最初の試行は失敗しますが、そうでlibjupcommon.aはありません。libjupcommon_a_CFLAGS = -fPIC著者はそれを修正するために追加します。ずっと良くなりますが、「共有ライブラリ libjupiter.la をスタティック ライブラリ ../common/libjupcommon.a に対してリンクすると、移植性がありません! 」という警告が表示されます。」が表示されます。

したがって、作成者は、libtool を使用して をビルドし、Makefile.am を再度変更しlibjupcommon.laます。へのlibjupiterリンクlibjupcommon.la。このような：

noinst_LTLIBRARIES = libjupcommon.la

libjupcommon_la_SOURCES = jupcommon.h print.c

と

...

libjupiter_la_LIBADD = ../common/libjupcommon.la

今回はすべてOKです。

今、私の問題：

libjupiterneedsと同じように、別のライブラリが必要なライブラリがありますlibjupcommon。違いは、私libjupcommonが別のプロジェクトからのもので、システムにインストールされていることです。ではありませんnoinst_LTLIBRARIES。.soと.aバージョンの両方が存在します。libjupcommon.la例のように をリンクしようとすると、.soが選択されますが、動的なリンク関係は必要ありません。本の例のように、にリンクしたい.a。

.a明示的に (_LIBADD=the .a ファイルを使用して) にリンクすると、使用可能なライブラリが得られますが、「... ポータブルではありません」という警告が表示されます。

.aこの場合、へのリンクを達成する適切な方法は何ですか?

PS:書籍の公式サイトからサンプルをダウンロードしてください。でautotools/book/jupiter-libtool-ch6/common、Makefile.am を変更して、私の問題によく似たものにする必要がありますnoinst_LTLIBRARIES。lib_LTLIBRARIES