間接的な依存関係にはリンクの問題があります。Web で読んだことから推測すると、2 レベルの名前空間の使用が原因である可能性があります。これは、boost ライブラリ、正確には boost_filesystem にリンクするときに発生します。これは、boost_system に依存しています。リンカーは、boost_filesystem と boost_system の間の依存関係を解決しません。誰かがこれを解決する方法を教えてもらえますか? 依存関係に手動で boost_system を追加するのは見苦しいだけでなく、他のプラットフォームでも問題なく動作します。
1012 次
2 に答える
2
Macの静的リンクエディタldの一部のバージョンは、-Lオプションを介して間接的な依存関係を解決せず、代わりに、直接的な依存関係に組み込まれているinstall_nameを介してそれらを検索します。boost_filesystenでotool-Lを実行すると、ldがboost_systemを探している場所が表示されます。
install_nameをinstall_name_toolで変更するか、
-dylib_file install_name：file_name
ldへのオプション。これは、コロンの前の引数の部分に一致するinstall_nameパスに出くわすたびに、コロンの後のパスから実際にそのライブラリを取得する必要があることをldに伝える方法です。
新しいバージョンのldは、Macへの間接的な依存関係について-Lを尊重していると思いますが、よくわかりません。私は間接的な依存関係に-Lを無視するldを持つ10.4のみを使用し、-dylib_fileを使用して、あなたが説明する問題を回避するために他の人が入れた多くの幻の明示的な依存関係を取り除きました！
于 2009-03-05T23:36:07.190 に答える
1
boost_filesystem が boost_system のシンボルを使用していて (そしてアプリケーションがそうではなく)、それらを解決するために直接 boost_system にリンクしている場合、それは機能するはずです。フラットな名前空間と 2 レベルの名前空間の問題は、リンク先のライブラリの依存関係によって提供されるシンボルがアプリ内で使用できると予想される場合に、一般的に頭に浮かびます。
boost_filesystem が boost_system に対してリンクしていない場合 (otool -L で表示されます)、boost_system に手動で依存関係を追加する以外に、再リンク以外の選択肢はほとんどありません。
boost は GNU libtool を使用しないと考えるのは正しいですか (ライブラリ間の依存関係をプラットフォーム固有の正しい方法で処理します)。もしそうなら、それは簡単な回避策かもしれません。
于 2009-01-14T15:54:50.097 に答える