I have an application that uses the JNI to call a C file that reads some system information. I have this running fine on Linux, but on Solaris 10 (SPARC, 32-bit) I am having trouble when the library is used. I compiled the C file on the same machine that I am testing it on with the command:
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
This compiles fine, but unlike on Linux, I had to include the path to the system OpenSSL, -I/usr/local/ssl/include. This is obviously the problem, as when the library is used, I get the following fatal error due to an OpenSSL type:
ld.so.1: java: fatal: relocation error: file /workspace/solaris_sparc/libosaccess.so: symbol EVP_aes_256_cbc: referenced symbol not found
Killed
I have tried adding the location of the system OpenSSL to the PATH and also my LD_LIBRARY_PATH, but continue to get the error. I have read that I can see the paths that my application is looking using ldd -d but can't quite seem to get this working as of yet.
Can anyone tell me if there is a way I can set where the OpenSSL files are so that all applications can find them? On my Linux machine, there are no environment variables that include the path to the OpenSSL on that. There is, however, a binary called openssl under /usr/bin, which is included in the PATH variable. I have found a binary on Solaris, but adding this to the PATH doesn't help.
EDIT
@ nudzo and Kenster
Ok so rather than try to squeeze this into the comments box for your answers, I thought I'd post it in addition to my question to improve the readability.
So I have checked my system and there is only the two copies of OpenSSL that I can find.
- Doing a
pkginfo | grep 'SUNWcry*'shows that I have the two additional packages installed. - Only the
/usr/sfwlocation has the two 'extra' libraries you mentioned - Both locations have the
evp.hheader file that includes theEVP_aes_256_cbcsymbol.
The locations are:
/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
I recompiled my C file using:
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
Again, omission of the path to the headers throws implicit declaration of function errors of the EVP types when compiling. This, however, still causes the same error as originally posted.
So if there are only these two copies on the system, that would indicate that instead of using the version shipped with Solaris (/usr/sfw), the system default is using the /usr/local copy that doesn't have the additional 'extra' shared objects. Would that be a fair assumption to make? How would I conclusively check this? I don't have permissions to remove either copy.
Also, running cryptoadm list -mv output a lot of information I didn't quite understand. However I found these entries in a couple of the slot tables:
CKM_AES_CBC 16 32 . X X . . . . . . . X X . .
and also:
Kernel software providers:
==========================
aes256: CKM_AES_ECB,CKM_AES_CBC,CKM_AES_CTR
Kernel hardware providers:
==========================
n2cp/0: CKM_DES_CBC,...,CKM_AES_CBC,...
I apologise for the huge amount of extra information.