0

http://java.sun.com/developer/onlineTraining/Programming/JDCBook/jniexamp.htmlにある JNI の記事について質問があります。

gcc  -o libnativelib.so -shared -Wl,-soname,libnative.so  
     -I/export/home/jdk1.2/include 
     -I/export/home/jdk1.2/include/linux nativelib.c  
     -static -lc

「-o libnativelib.so」と「-Wl,-soname,libnative.so」の機能について、まだ少し混乱していると思います。

-o libnativelib.so は、gcc の出力ファイル名を libnativelib.so に指定します。私が理解していることから、記事に示されているように、JAVA 側からロードするライブラリ名です。

  static {
    System.loadLibrary("nativelib");
  }

では、'-Wl,-soname,libnative.so' の用途は何ですか?

ld オプションのマニュアルで次の情報を見つけました。

-soname=名前

ELF 共有オブジェクトを作成する場合、内部 DT_SONAME フィールドを指定された名前に設定します。実行可能ファイルが DT_SONAME フィールドを持つ共有オブジェクトにリンクされている場合、実行可能ファイルが実行されると、ダイナミック リンカーは、リンカーに指定されたファイル名を使用するのではなく、DT_SONAME フィールドで指定された共有オブジェクトをロードしようとします。

それで、それはどういう意味ですか？最終的な実行可能ファイルが実行されると、リンカーはロードを試みますか?? それよりも ？？の名の下に ？？

4

2 に答える 2

0

GCC-HOWTOから：

各ライブラリにはsonameがあります。リンカは、検索しているライブラリでこれらの1つを見つけると、調べている実際のファイル名ではなく、バイナリにsonameを埋め込みます。実行時に、動的ローダーは、ライブラリのファイル名ではなく、sonameの名前のファイルを検索します。したがって、libfoo.soという名前のライブラリにlibbar.soという名前を付けることができ、それにリンクされているすべてのプログラムは、起動時に代わりにlibbar.soを探します。

あなたの場合、sonamelibnative.soはファイル名とは異なりますlibnativelib.so。ダイナミックローダーが共有ライブラリを見つけられるようにするには、シンボリックリンクする必要がありますlibnative.so。libnativelib.so

于 2012-08-22T12:10:15.290 に答える
0

これは、1 つのライブラリが libz.so、libz.so.1、libz.so.1.2.3 などの複数の名前で存在する可能性があるシステムで役立ちます。これらのライブラリはすべて 1 つのファイルへのシンボリック リンクであり、その中の DT_SONAME は "libz.so.1" を指しています。コードを libz.so にリンクすると、実行可能ファイルに「libz.so.1」への依存関係が記録されます。また、たとえば libz.so.1.2.5 を含む別のシステムでファイルを実行しても、libz.so.1 を探すため、ファイルは機能します。しかし、目的のシステムに libz.2.3.4 のようなもっと新しいバージョンがある場合、libz.so.2 は存在するが libz.so.1 は存在しないため、失敗します。

DT_SONAME フィールドはリンカーによってのみ使用されます。System.loadLibrary() を使用する場合、ファイル名はユーザーが指定し、このオプションの値は使用されません。必要に応じて、libnative に同様のバージョン管理スキームを実装して、Java コードが常に互換性のあるバージョンをロードするようにすることができます。

于 2012-08-22T11:48:27.127 に答える