Problem in loading Native libraries
While trying to load native libraries I'm getting the following error message
java.lang.UnsatisfiedLinkError: /XXX/XXX/libMySharedObj.so: ld.so.1: <JAVA_HOME>/bin/sparcv9/java: fatal: libskgxp10.so: open failed: No such file or directory
At which place the 'libskgxp10.so' file should present and from where I can get a copy of the same?
I'm using webLogic 8.15 on a solaris(5.8) box. The JVM has been started in 64bit mode with the options JAVA_VM="-server" and JAVA_OPTIONS="-d64" in the 'startWebLogic.sh' script.
Any idea to fix this issue?
[587 byte] By [
Amit.Pola] at [2007-11-26 17:20:05]
# 2
Thanks for the response.
I do load the native library "libMySharedObj.so" by System.load() with it's absolute path.
Here I'm confused about the other library 'libskgxp10.so' which appears in the error message.
java.lang.UnsatisfiedLinkError: /XXX/XXX/libMySharedObj.so: ld.so.1: <JAVA_HOME>/bin/sparcv9/java: fatal: libskgxp10.so: open failed: No such file or directory.
The only thing is that the library "libMySharedObj.so" which I wants to upload was created on a diffenent machine. Is that the problem is because of this?
# 3
Looks like your shared klibrary calls methods in another shared library. Since you changed computers, it's possible that the missing library is, in fact, missing.
# 4
Suspecting the same, I've tried to run the application in the same machine where the shared object has been created.
This time I got the error message as
java.lang.UnsatisfiedLinkError: /XXX/XXX/libMySharedObj.so: ld.so.1: <JAVA_HOME>/bin/java: fatal: /XXX/XXX/libMySharedObj.so: wrong ELF class: ELFCLASS64.
I have created the native library 'libMySharedObj.so' by the following way
gcc -c xxx.c
gcc -c yyy.c
gcc -c zzz.c
ld -G xxx.o yyy.o zzz.o -o libMySharedObj.so -lm -lc -lpthread
Please advice if I'm taking the wrong track somewhere or with any alternative approach.
# 6
All,
My experience is that the primary library loaded by Java with System load can be pointed to using java.library.path, but any dependencies on the native side are searched for using the path on windows or LD_LIBRARY_PATH on unix. If the dependency is not located in one of the standard places then you have to append one of the second values.
Jim
