JNI issue on Linux: cannot open shared object file - linux

Question

I've seen this question on here, tried the proposed fixes, but no success so far for me. I have quite some Java experience, but JNI is a long time ago, never did it on Linux though...
I'm trying to get a simple HelloWorld JNI app running on Linux.
Small java file:
class HelloWorld {
private native void print();
public static void main(String[] args){
new HelloWorld().print();
}
static {
System.out.println(System.getProperty("java.library.path"));
System.loadLibrary("HelloWorld");
}
}
Small C file:
#include <jni.h>
#include <stdio.h>
#include "HelloWorld.h"
JNIEXPORT void JNICALL
Java_HelloWorld_print(JNIEnv *env, jobject obj)
{
printf("Hello World!\n");
return;
}
compiled the C file by:
gcc -shared -Wall -fPIC HelloWorld.c -I/usr/lib/gcc/x86_64-redhat-linux/3.4.3/include/ -o libHelloWorld.so
Run the app by:
java HelloWorld
or
java -Djava.library.path=/home/nxp40954/jnitesting/. HelloWorld
But no good, getting a:
Exception in thread "main" java.lang.UnsatisfiedLinkError: /home/nxp40954/jnitesting/libHelloWorld.so: /home/nxp40954/jnitesting/libHelloWorld.so: cannot open shared object file: No such file or directory
Strange, because there is actually a /home/nxp40954/jnitesting/libHelloWorld.so file.
Does anyone have a clue?

Answer 1

execute this way:
export LD_LIBRARY_PATH=.
java HelloWorld
The java.lang.UnsatisfiedLinkError is thrown when the .so file cannot be loaded.
The LD_LIBRARY_PATH variable points extra location to look for the *.so files.
I'm on 32bit ubuntu with sun java. I was compiling this way:
gcc -shared -Wall -fPIC HelloWorld.c -I/usr/lib/jvm/java-6-sun-1.6.0.26/include -I/usr/lib/jvm/java-6-sun-1.6.0.26/include/linux -o libHelloWorld.so

Answer 2

Your example worked for me on a 32-bit Linux installation.
Is your shared library compiled as a 32-bit or 64-bit shared library? Check with command file libHelloWorld.so. If your shared library is 64-bit then you need to give command line option -d64 when starting Java so that Java can load the 64-bit shared library.
If your shared library is 32-bit then perhaps the Java option -d32 will solve the problem.

Answer 3

Clarification on java.library.path and system path:
java.library.path is a JVM-Variable which can be set - e.g. - by the command line parameter
-Djava.library.path=xy
DLL's (on windows) and so's (on linux) which are loaded by the java call loadLibrary() must be located in the java.library.path. If it is loaded via JNI it must be located in the system path.
If such a linked library loads another linked library, latter must be found in the system path. In Windows the system path is resolved against the PATH environment variable, in linux it's the LD_LIBRARY_PATH environment variable (for linked libraries).
Another point to ensure in linux: Verify that the linked library has executable permissions for the current user. Usually a
sudo chmod 755 myLinkedLib
does the trick.