問題タブ [dlopen]

関数「dlopen（）」を使用してiOSプラットフォームでダイナミックライブラリを呼び出したいのですが、関数「dlopen（）」はプライベートAPIですか？

共有ライブラリが不良です（未定義のシンボル）。

初めてdlopen（）を呼び出すと、dlerror（）から正しいエラーメッセージが表示されたNULLの結果が得られます。

エラーメッセージを無視し、同じ引数を使用してdlopen（）を呼び出すと、2回目にnull以外のハンドルが取得されます（これは、ライブラリが正常にロードされたことを示します）。これは明らかに間違っています。

この問題はUbuntu11.04で発生します（IIRC、10.10にはこの問題はありませんでした）。Centos5.5ではこの問題は発生しません。

特に、この問題はTclインタープリター内で発生します。最初に正規化された絶対パスを使用して共有ライブラリをロードしようとします。それが失敗した場合は、ユーザーが指定した正確なパス文字列を使用して文字通り再び失敗します。私の場合、両方とも失敗するはずですが、Ubuntu11.04では2番目の呼び出しが正しく成功していません。

奇妙なことに、この問題を再現できるのは、正確な本番共有ライブラリを使用した場合のみです。縮小された共有ライブラリを作成すると、正しく機能しています。

このようなプログラムは、私の本番ライブラリの問題を示すのに十分です。

別のプログラムから関数を呼び出す必要があります。他のプログラムがライブラリの場合、dlopen と dlsym を使用して関数のハンドルを取得できます。残念ながら、もう一方のプログラムは Unix Executable であり、ライブラリとしてビルドすることはできません。実行可能ファイルで dlopen() を試行すると、次のエラー メッセージが表示されます。

dlopen([...]/testprogram, 1): no suitable image found. Did find: [...]/testprogram: can't map

dlopen は実行可能ファイルではなくライブラリで使用するためのものであるため、これは驚くべきことではありません。dlopen と dlsym を実行可能ファイルで動作させる方法はありますか? そうでない場合、同じことを達成する別の方法はありますか?

私のプログラムには、次のようなコードがあります

内/* .. */で、メモリ マップ ファイルを読み取って、マップ/proc/self/maps先の仮想メモリ アドレスを見つけるlibname必要があります。また、ライブラリを開いてその中の特定のセクションを見つける必要もあります。このためには、さまざまな場所 (キャッシュ ファイルdlopenなど) を検索して見つかった絶対名が必要です。ldconfigそのファイル名を受け取るにはどうすればよいですか?

これが私が最終的に得たものです（はい、これはC++コードですが、CタグはdlopenC++とCの両方で使用され、私の質問は両方に適格であり、POSIXはCに対してそれを指定しているため、この質問には意味があります. ）。

libfile相対/プレーンファイル名です。マップはプレーンでないファイル名を生成します (つまり、そうではありませんfoo.soが、そうかもしれません./foo.so)。その後realpath、最終的な絶対パス名を取得していました。それはうまく機能します！

私が取り組んでいるプロジェクトでは、追加機能を動的にロードする機能を提供しています。そのために、dlopen を使用します。

このライブラリを見つけるために、モジュール パスと呼ばれるものがあります。そこには、共有ライブラリがあるデフォルトのパスがあります (それらの多くは出荷されています)。

現時点では、2 つのデフォルト パスがあります。最初に共有ライブラリのビルド ディレクトリを検索し、その後でインストール ディレクトリを検索します。これは、アプリケーションをインストールせずにアプリケーションを実行することも可能である必要があるためです (その場合、ビルド ディレクトリを最初に検索する必要があります)。

問題は、ユーザーがアプリケーションをソースからビルドして make install でインストールすると、ビルド ディレクトリのライブラリがデフォルトで読み込まれることです。これにより、クラッシュが発生します。そのため、後でユーザーがビルド ディレクトリを削除または名前変更した場合にのみ機能します。

質問はありません: アプリケーションがインストールされているかどうかを知るための (C++ またはビルド システムによる) トリックはありますか。問題は、機能が共有ライブラリに実装されており、モジュールを検索するために実装された方法が、ライブラリにリンクする他のアプリケーションでも機能する必要があることです (したがって、実行可能ファイルのパスに依存することはできません)。ビルドシステムとして CMake を使用しています。

状況をさらに困難にするために、このソリューションは Windows、Linux、および Mac OS X で動作する必要があります。

編集：

さらに調査したところ、問題はより複雑になりました。これは状況です：

• 小さな実行可能ファイルがあります
• さらに、「メイン」ライブラリ main.so があります。
• 次に、動的にロードされたライブラリ lib.so があります
• main.so に対する lib.so リンク

問題は、lib.so の rpath にビルド ディレクトリの main.so への絶対パスがあることです。@MSalters のヒントのおかげで、正しいバージョンの lib.so (インストール ディレクトリにあるもの) を確実にロードするようにハックすることができましたが、rpath にビルド パスがあるため、間違ったメインをロードします。 .so (つまり、実際には、メモリ内に main.so の 2 つのコピーがあります。これは混乱を招きます)。

ライブラリからビルド パスへのこの参照を削除する方法はありますか? rpathに関連するcmakeのすべてのオプションを試しましたが成功しませんでした

最初に.dylibをロードするソフトウェアがあり、次のコマンドを使用してlibFirst.dylibを呼び出すことができます。

後で、ロードされたlibFirst.dylibから関数内で、同じコマンドを使用して別の.dylibをロードしようとしますが、libSecond.dylibの場合、この共有ライブラリをロードすると、Xcodeコンソールに次の警告が表示されます。

私が得られないのは、libFirst.dylibがロードされていないということですが、現在libFirst.dylibの関数内にいるので、どうすればよいでしょうか。

DYLD_LIBRARY_PATHのすべてのパスも正しいように見えます。

事前のおかげで、私はこれに何日も立ち往生しています。

setenv を使用して DYLD_LIBRARY_PATH を設定しているため、dlopen() を実行すると、.dylib を見つけるための正しいパスが得られますが、dlopen() を実行すると、DYLD_LIBRARY_PATH に追加したパスが検索されないようです。

収集できるものから、DYLD_LIBRARY_PATH への変更は、プロセスが再実行されるまで有効になりません。これは正しいです？

また、それが正しければ、DYLD_LIBRARY_PATH を設定し、プロセスをリセットせずに変更を機能させる方法はありますか。

そうそう、私はこのコードを MAC OSX で書いています。

前もって感謝します。

dlopen を使用して .dylib ファイルをロードするための @rpath を見つけたので、それらを理解するための助けが必要です。OSX マシンで Xcode 3.2.5 を使用しています。

他の .dylib を呼び出し、互いに呼び出す .dylib がいくつかあります。@rpath は、ロードされた最初の .dylib に対して機能するようですが、@rpath を使用して以前に検出およびロードされた最初の .dyblib ファイルを使用する別の .dylib で dlopen 呼び出しを行うと、dlopen は、それが可能であると言って失敗します。元の .dylib を見つけません。

@rpath は、dlopen で使用されているファイルに対してのみ機能しますか?それとも、開かれている dylib ファイル内の依存関係を解決するためにも使用されていますか?

アップデート：

私のさらなる発見により、相互依存関係を @rpath を持つように変更するために install_name_tools を使用するようになりました。これはこれを行う正しい方法ですか？

かなりの数の共有ライブラリで構成されているアプリケーションがあります。私はそれらのいくつかに perl 拡張機能を書きました。また、アプリケーションに perl を組み込みました。

C++ で perl スクリプトを呼び出しています。たとえば、私の perl 拡張機能の名前は SV::Net::Info および SV::Interface で、私の perl ファイルは次のようになっています。

C++ から perl スクリプトを読み取り、問題なく出力を C++ に送り返すことができます。3行目のコメントを外すと問題が発生し、次のuse IO::Socket;エラーメッセージが表示されます

これは、IO 自体が C ライブラリであるためです。ここで述べたように xs-glue を追加しました。追加された接着剤が boot_IO シンボル (IO.so ファイルで定義されている) を探しているため、問題は解決しませんでした。アプリケーションを IO.so とリンクできません。これは、実行時に perl が dlopen を使用して開くファイルであるためです。(また、私のアプリケーションは Windows で動作するはずであり、Windows は .lib ファイルではなく .dll ファイルのみを提供します)。抜け道は？

dlopen を使用して実行時に IO.so から実際の boot_IO 関数を実行するラッパー関数 boot_IO を作成することを考えています。これが唯一のオプションですか？

dlopen を使用して libc メモリ割り当て関数のハンドルを取得する方法を教えてもらえますか? 特に、libc パスを検索してからハンドルを取得するようなものです。dlsym を呼び出すには、どのモードを使用する必要がありますか?

アイデアは次のとおりです。

1. libc パスを検索
2. その上で dlopen を呼び出します
3. dlsym を使用してメモリ関数 (malloc、calloc など) にアクセスし、
4. 関数を使用する

上記の 4 つの手順のコード スニペットを教えてください。