JNI を使用して、システム情報を読み取る C ファイルを呼び出すアプリケーションがあります。これは Linux では問題なく動作しますが、Solaris 10 (SPARC、32 ビット) ではライブラリを使用すると問題が発生します。次のコマンドを使用して、テストしているのと同じマシンで C ファイルをコンパイルしました。
gcc -O2 -fPIC -shared -static-libgcc -I/usr/local/ssl/include \
-I$JAVA_HOME/include -I$JAVA_HOME/include/solaris -lcrypto \
-lm -std=c99 -o libosaccess.so osaccess.c
これは正常にコンパイルされますが、Linux とは異なり、システム OpenSSL へのパスを含める必要がありました-I/usr/local/ssl/include。これは明らかに問題です。ライブラリを使用すると、OpenSSL タイプが原因で次の致命的なエラーが発生します。
ld.so.1: java: fatal: relocation error: file /workspace/solaris_sparc/libosaccess.so: symbol EVP_aes_256_cbc: referenced symbol not found
Killed
PATHシステムの OpenSSL の場所を と自分の に追加しようとしましたLD_LIBRARY_PATHが、引き続きエラーが発生します。アプリケーションが使用しているパスを確認できることを読みましたldd -dが、まだこれが機能しているようには見えません。
すべてのアプリケーションがそれらを見つけられるように、OpenSSL ファイルの場所を設定できる方法があるかどうか、誰か教えてもらえますか? 私の Linux マシンには、OpenSSL へのパスを含む環境変数がありません。ただし、変数に含まれるopensslunderと呼ばれるバイナリがあります。Solaris でバイナリを見つけましたが、これを に追加しても役に立ちません。/usr/binPATHPATH
編集
@nudzo と Kenster
わかりましたので、回答のコメント ボックスにこれを押し込むのではなく、読みやすさを向上させるために質問に加えて投稿すると思いました。
システムをチェックしたところ、OpenSSL のコピーが 2 つしか見つかりませんでした。
pkginfo | grep 'SUNWcry*'実行すると、2 つの追加パッケージがインストールされていることがわかります。/usr/sfwあなたが言及した2つの「追加の」ライブラリがあるのはその場所だけです- どちらの場所にも、シンボル
evp.hを含むヘッダー ファイルがあります。EVP_aes_256_cbc
場所は次のとおりです。
/usr/sfw
xxx-1035> find /usr/sfw -type f -name 'openssl'
/usr/sfw/bin/openssl
xxx-1036> find /usr/sfw -type f -name 'evp.h'
/usr/sfw/include/openssl/evp.h
xxx-1037> find /usr/sfw -type f -name 'libcrypto*'
/usr/sfw/lib/sparcv9/libcrypto.so.0.9.7
/usr/sfw/lib/sparcv9/libcrypto_extra.so.0.9.7
/usr/sfw/lib/libcrypto.so.0.9.7
/usr/sfw/lib/libcrypto_extra.so.0.9.7
xxx-1038> find /usr/sfw -type f -name 'libssl*'
/usr/sfw/lib/sparcv9/libssl.so.0.9.7
/usr/sfw/lib/sparcv9/libssl_extra.so.0.9.7
/usr/sfw/lib/libssl.so.0.9.7
/usr/sfw/lib/libssl_extra.so.0.9.7
/usr/local/ssl
xxx-1040> find /usr/local/ssl -type f -name 'openssl'
/usr/local/ssl/bin/openssl
xxx-1041> find /usr/local/ssl -type f -name 'evp.h'
/usr/local/ssl/include/openssl/evp.h
xxx-1042> find /usr/local/ssl -type f -name 'libcrypto*'
/usr/local/ssl/lib/libcrypto.a
/usr/local/ssl/lib/libcrypto.so.0.9.7
/usr/local/ssl/lib/libcrypto.so.0.9.8
/usr/local/ssl/lib/pkgconfig/libcrypto.pc
xxx-1043> find /usr/local/ssl -type f -name 'libssl*'
/usr/local/ssl/lib/libssl.a
/usr/local/ssl/lib/libssl.so.0.9.7
/usr/local/ssl/lib/libssl.so.0.9.8
/usr/local/ssl/lib/pkgconfig/libssl.pc
以下を使用して C ファイルを再コンパイルしました。
gcc -O2 -fPIC -shared -static-libgcc \
-I$JAVA_HOME/include -I$JAVA_HOME/include/solaris \
-I/usr/sfw/include -L/usr/sfw/lib -R/usr/sfw/lib \
-lcrypto -lm -std=c99 -o libosaccess.so osaccess.c
ここでも、ヘッダーへのパスを省略すると、implicit declaration of functionコンパイル時に EVP タイプのエラーがスローされます。ただし、これにより、最初に投稿されたものと同じエラーが引き続き発生します。
したがって、システムにこれらの 2 つのコピーしかない場合は、Solaris に同梱されているバージョン ( /usr/sfw) を使用する代わりに、システムのデフォルトで/usr/local、追加の「余分な」共有オブジェクトを持たないコピーが使用されていることを示します。それは公正な仮定でしょうか？これを最終的に確認するにはどうすればよいですか？どちらのコピーも削除する権限がありません。
また、cryptoadm list -mv出力を実行すると、よくわからなかった多くの情報が出力されました。ただし、いくつかのスロット テーブルでこれらのエントリを見つけました。
CKM_AES_CBC 16 32 . X X . . . . . . . X X . .
また:
Kernel software providers:
==========================
aes256: CKM_AES_ECB,CKM_AES_CBC,CKM_AES_CTR
Kernel hardware providers:
==========================
n2cp/0: CKM_DES_CBC,...,CKM_AES_CBC,...
膨大な量の追加情報をお詫び申し上げます。