我有一個應用程序使用JNI調用讀取某些系統信息的C文件。我在Linux上運行良好，但在Solaris 10（SPARC，32位）上，使用庫時遇到問題。我編，我就用命令測試它在同一臺機器上的C文件：應用程序找不到用於編譯庫的OpenSSL
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
我試圖把系統的OpenSSL的位置到PATH，也是我LD_LIBRARY_PATH，但繼續得到錯誤。我已經讀過，我可以看到我的應用程序使用ldd -d查找的路徑，但似乎無法使此工作到現在爲止。
任何人都可以告訴我，如果有一種方法可以設置OpenSSL文件的位置，以便所有應用程序都可以找到它們嗎？在我的Linux機器上，沒有包含OpenSSL路徑的環境變量。但是，在/usr/bin下有一個名爲openssl的二進制文件，該文件包含在PATH變量中。我在Solaris上找到了一個二進制文件，但將其添加到PATH沒有幫助。
編輯
@ nudzo和Kenster
好了，所以，而不是試圖擠進你的答案的評論欄中這一點，我想我會發布它除了我的問題，以改善可讀性。
所以我檢查了我的系統，並且只有兩個可以找到的OpenSSL副本。
- 做一個
pkginfo | grep 'SUNWcry*'表明我有兩個額外的軟件包安裝。 - 只有
/usr/sfw位置有你提到 - 這兩個地點都包含
EVP_aes_256_cbc符號evp.h頭文件中的兩個「額外」庫。
的位置是：
在/ 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 /本地/ 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
同樣，在編譯時，忽略頭文件的路徑會引發EVP類型的錯誤implicit declaration of function。但是，這仍然會導致與原始發佈相同的錯誤。
因此，如果系統上只有這兩個副本，則表示不使用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,...
我爲額外的龐大的信息量道歉。
使用'LD_LIBRARY_PATH'應該是要走的路......你如何使用它？我以前從來沒有必須將它與Java結合使用，但我懷疑它沒有傳遞到需要的地方。 –