2011-12-05 11 views
0

基本的に、jarファイル内の共有オブジェクトのコレクションを圧縮し、実行時に一時ディレクトリに解凍し、そこ。私は図書館を持って、たとえば言う:ライブラリを一時ディレクトリに解凍し、そのディレクトリからすべての依存ファイルをロードする方法

  • libApp.so
  • libBasicPlugin.so => libApp.so
  • libPlugin1.so => libApp.so、libBasicPlugin.so、libPlugin2.so
  • libPlugin2.so => libApp.so、libBasicPlugin.so

Javaは、任意の、一意の一時ディレクトリ$ USER_HOME/.MYアプリ/ 2011_12_05_001 /それらを解凍して、libApp.soをロードし、順番に用途libPlugin1とlibPlugin2をロードするためのdlopen(libBasicPlugin is is明示的にロードされていない)。問題は、libPlugin1がlibBasicPluginとlibPlugin2を見つける場所を知らないことです。

  1. が知られている場所にライブラリを置くとJavaを呼び出す前にSHファイルでLD_LIBRARY_PATHを設定:ここでは

    は私が考えられて/試してみました様々なソリューションです。これは動作しますが、ライブラリをjarファイルにパッケージ化することはできません。

  2. JavaのSystem.loadを使用して依存関係を事前にロードします。これは私が提案したアプローチですが、プラグインがどのように読み込まれ、その依存関係が分かっているかを先験的に知っていればうまくいくようです。 UnsatisfiedLinkExceptionsの取得を停止するまで、ディレクトリ内のすべてのファイルを反復しない限り...
  3. 何とかその依存関係が(DT_RPATH経由で)同じディレクトリに存在することを共有オブジェクトに伝えます。これは私が理想的な世界で欲しいと思うものですが、実行可能ファイル(この場合は/usr/lib/jvm/.../java)に相対的なライブラリの場所を設定するのが最善の方法です。
  4. 各ライブラリをその依存関係で静的にリンクします。私は、これがlibPlugin2(動的なものと静的なもの)の2つのコピーをもたらし、過去に私たちのためにあらゆる種類の問題を引き起こしているのではないかと心配しています。

Windowsでは、プラグインをロードする前にSetDllDirectoryを呼び出すとこれがうまく解決されます。私が見落としている/誤解している解決策はありますか?私はこれについて完全に間違った方法をしていますか?

答えて

0

LD_LIBRARY_PATH env varをJavaプロセス自体から設定できます。

+0

ありがとう、私は同じ考えを持っていましたが、Linuxはアプリケーションを初めて実行するときにLD_LIBRARY_PATHをキャッシュします。実行時に変更することはできません。 http://stackoverflow.com/questions/856116/changing-ld-library-path-at-runtime-for-ctypes – kylewm

+0

OK。それは残念だ。 –

関連する問題