I want to call a C program from Java program using JNI in linux ubuntu.
I am new to this and I have tried the sample program given in http://www.ibm.com/developerworks/java/tutorials/j-jni/section2.html
. I have already created the .java, .h , .c and .so files. But when i tried to run the program I am getting the following error.
Exception in thread "main" java.lang.UnsatisfiedLinkError: no Sample1 in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1738)
at java.lang.Runtime.loadLibrary0(Runtime.java:823)
at java.lang.System.loadLibrary(System.java:1028)
at Sample1.main(Sample1.java:13)
This exception is indicating that the .so is not available to the JVM.
Adding the directory where the .so exists to the LD_LIBRARY_PATH will resolve this. If the .so depends on other .so libraries the directories where these .so exist will also need added to LD_LIBRARY_PATH.
I've just tried to get the same sample to work on my CentOS and got the same error as you. As already answered, JVM failed to find the so file needed. I succeeded to get it to work by following the steps below using gcc:
$ javac Sample1.java
$ javah Sample1
$ # Include paths must also be specified using -I option in the following gcc command line!
$ gcc -shared -I...snip... Sample1.c -o libSample1.so
$ # Library path for libSample1.so must also be specified!
$ java -Djava.library.path=...path/to/libSample1.so... Sample1
If you omit the "lib" prefix of the shared library, JVM fails to find it for some reason.
I don't know why. I am not familiar with the naming convention of shared libraries in Linux.
I hope this post could help.
Related
I try to get this maven projekt to run on the Raspberry Pi 3 but the DHT11 sensor gives me the following error:
sudo java -classpath '.:classes:*:classes:/opt/pi4j/lib/*' com.epam.llpd.greenhouse.web.ServerStarter
java.lang.UnsatisfiedLinkError: no dhtreader in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1864)
at java.lang.Runtime.loadLibrary0(Runtime.java:870)
at java.lang.System.loadLibrary(System.java:1122)
at com.epam.llpd.greenhouse.sensor.Sensor.<clinit>(Sensor.java:16)
at com.epam.llpd.greenhouse.PiHardwareController$1.run(PiHardwareController.java:132)
In the folder \src\main\java\com\epam\llpd\greenhouse\sensor there is the dhtreader.c file.
I did compile a binary objekt with the following command:
gcc -o dhtreader.so -lc -shared -I/usr/lib/jvm/jdk-7-oracle-arm-vfp-hflt/include -I/usr/lib/jvm/jdk-7-oracle-arm-vfp-hflt/include/linux dhtreader.c -l bcm2835
The dhtreader.so is placed in the same folder as the .jar.
The dhtreader.c file is a common C class specific for the Raspberry Pi to use the DHT11 and DHT22 sensor and it is used in many Raspberry Pi projects and has alot of sources like this one.
This C class (dhtreader.c) is used via. JNI/C but it just doesn't work because of the error above.
I allready tried to set the java.library.path with the following method in the java main:
System.setProperty("java.library.path", "./");
That didn't help. Instead i added -Djava.library.path=./ to the java command:
sudo java -classpath '.:classes:*:classes:/opt/pi4j/lib/*' com.epam.llpd.greenhouse.web.ServerStarter -Djava.library.path=./
But that didn't help neither.
Now i'm stuck and don't know how to add the dhtreader.so to the java.library.path.
How do i add the dhtreader.so to the java.library.path?
I asked in the Raspberry Pi StackExchange first but they thought that it's off-topic.
Try to simply rename dhtreader.so to libdhtreader.so.
Indeed when we call System.loadLibrary("foo") in java the expected name of the library is:
Windows: foo.dll
Unix/Linux: libfoo.so
Mac: libfoo.jnilib
Try to launch it as next:
sudo java -Djava.library.path=./lib -classpath '.:classes:*:classes:/opt/pi4j/lib/*' com.epam.llpd.greenhouse.web.ServerStarter
NB: The command above assumes that your lib is located in the lib directory that is itself located in the directory where the command has been launched.
Assimp is a library used for importing 3D models into your application. It is written for C++, but there is a port for java called jassimp. For the past 5 or 6 hours I've been trying to set up jassimp in Eclipse and cannot get it to work. I downloaded the win-binaries version of assimp here, which also includes ported versions of it like jassimp. I will now posts the steps I have taken to get jassimp to function in hopes that someone will be able to identify an error.
I've mainly followed the "tutorial" shown here, which basically consists of the two parts under "HOW TO BUILD."
Keep in mind, I didn't and still don't really know what any of those commands mean. Anyways, I had to install MinGW since I'm not using Linux and because I could not find the equivalent in DOS commands. After changing the paths to point to the same places his did, my command looked like this:
gcc jassimp.cpp -I "C:/Program Files/java/jdk1.8.0/include" -I "C:/Program Files/java/jdk1.8.0/include/win32" -lassimp -shared -fPIC -o libjassimp.so
I ran it, but there was a problem I encountered::
jassimp.cpp:3:28: fatal error: assimp/cimport.h: No such file or directory
#include <assimp/cimport.h>
"Okay," I thought. "Well, those -I commands probably include files or something, so maybe I should look for the header file that's missing and include it via -I!" Thus, I looked through the jassimp folder for a "cimport.h" file, and what do you know, I found it in a folder called include. I then proceeded to change my command to
gcc jassimp.cpp -I "C:/Program Files/java/jdk1.8.0/include" -I "C:/Program Files/java/jdk1.8.0/include/win32" (new->)-I "C:/assimp-3.1.1-win-binaries/include/"(<-new) -lassimp -shared -fPIC -o libjassimp.so
Upon running it, I was very surprised to see that I got another error:
C:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: cannot find -lassimp
"Hmmm..." I thought. After some googling, I found this answer. So, I went ahead and did what he did, and strangely enough, I saw that it was looking in some random folders for files called libassimp.dll, assimp.dll.a, libassimp.a, etc... "Hey, you shouldn't be looking in those folders!" I screamed.
"So how do I get it to look in the right location?" I wondered. Luckily, I found this answer. "Hmmm... he put -L and then the location of his library and then called -l< library >..." As I was thinking about how I was going to modify my command, I realized I was missing a little detail: what's the library I'm even trying to point to? Well, in the --verbose command, it looked like a file with a general name of assimp.lib or assimp.dll. And so, I searched the jassimp folder in hopes of finding a similar file. I found one named assimp.dll in a folder called bin64. I then changed my command once again:
gcc jassimp.cpp -I "C:/Program Files/java/jdk1.8.0/include" -I "C:/Program Files/java/jdk1.8.0/include/win32" -I "C:/assimp-3.1.1-win-binaries/include/" (new->)-L "C:/assimp-3.1.1-win-binaries/bin64"(<-new) -lassimp -shared -fPIC -o libjassimp.so
Running it gave me this error:
C:/assimp-3.1.1-win-binaries/bin64/assimp.dll: file not recognized: File format not recognized
So, I decided to build assimp as if I was using it for c++ in order to hopefully get a functional .dll file (I was really desperate...). I followed this (http:// assimp.sourceforge.net/lib_html/cmake_build.html) tutorial for building it, which uses CMake. Eventually, I built the project using CMake, which apparently just sets it up for use in Visual Studio, opened it in Visual Studio 2013, and built a release version of it from there. This gave me a .dll file which I then changed my command to point to:
gcc jassimp.cpp -I "C:/Program Files/java/jdk1.8.0/include" -I "C:/Program Files/java/jdk1.8.0/include/win32" -I "C:assimp-3.1.1-win-binaries/include/" (new->)-L "C:/assimp build/code/Release/"(<-new) -lassimp -shared -fPIC -o libjassimp.so
Well, at least it gave me a different error:
C:\Users\Nick\AppData\Local\Temp\ccgtrCg8.o:jassimp.cpp:(.eh_frame$_ZN7JNIEnv_9NewObjectEP7_jclassP10_jmethodIDz+0x13): undefined reference to `__gxx_personality_v0'
C:\Users\Nick\AppData\Local\Temp\ccgtrCg8.o:jassimp.cpp:(.eh_frame+0x14b): undefined reference to `__gxx_personality_v0'
c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: C:\Users\Nick\AppData\Local\Temp\ccgtrCg8.o: bad reloc address 0x14b in section `.eh_frame'
Googled it and just changed gcc to g++ and lo and behold, I got a file called libjassimp.so. Part 1 done. Or so I thought.
Time for part 2, which was relatively easier, so I'll just say I successfully ended up with a jassimp.jar file.
Time to put it all into my Eclipse project, which just consisted of me adding the jar file to the build path and attaching the libjassimp.so to the jar's native location. Upon trying to use one of the classes from jassimp, I came upon this little guy:
Exception in thread "main" java.lang.UnsatisfiedLinkError: no jassimp in java.library.path
I don't feel like explaining my thought process for this next part, so long story short, I changed the output file name in my command as such:
from
-o libjassimp.so
to
-o jassimp.dll
Genius, right? Running it with the new native file, I am now stuck with this:
Exception in thread "main" java.lang.UnsatisfiedLinkError: C:\Users\MyName\workspace\jassimp\lib\native\jassimp.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform
Google says using -m64 will compile a .dll to be 64-bit, so I tried
g++ jassimp.cpp ... -m64 -o jassimp.dll
And, not very surprisingly, I got this error while trying to compile it from the command line:
jassimp.cpp:1:0: sorry, unimplemented: 64-bit mode not compiled in
If I messed up anywhere, I would have to guess it was when I changed the name output file from .so to .dll, but I don't know what else to do. I also could've messed up anywhere else.
Anyways, I'm stuck, and I honestly don't know what else I can do here. There doesn't seem to be many posts on this topic, but it seems that some other people have gotten it to work and I am just stupefied by it, since I don't know any other process other than mine that they could have taken. There is one solution I've read, which is using a 32-bit jvm/jdk/jre/whatever, but I read that a 64-bit computer is more efficient than 32-bit so I don't want to do that.
Got it working. Turns out I was using a 32-bit version of MinGW which was why I was compiling a 32-bit .dll. I also did not need to build assimp with CMake or Visual Studio: I could have simply used the assimp.lib and assimp.dll files located in the win-binaries assimp folder. The final command is here:
g++ jassimp.cpp -I "C:/Program Files/java/jdk1.8.0/include" -I "C:/Program Files/java/jdk1.8.0/include/win32" -I "C:/Users/Nick/Desktop/java libraries/assimp-3.1.1-win-binaries/include/" -L "C:/Users/Nick/Desktop/java libraries/assimp-3.1.1-win-binaries/bin64" -L "C:/Users/Nick/Desktop/java libraries/assimp-3.1.1-win-binaries/lib64" -lassimp -shared -fPIC -o -m64 jassimp.dll
The -m64 is unnecessary, but I put it there just to make sure that the dll compiles as 64 bit. Also, when I used the new jassimp.dll in Eclipse, I got an unsatisfied link error:
Exception in thread "main" java.lang.UnsatisfiedLinkError: C:\Users\MyName\workspace\myproject\lib\jassimp-native\jassimp.dll: Can't find dependent libraries
I fixed this by putting the assimp.dll file from assimp-3.1.1-win-binaries/bin64 into my system32 folder.
Hopefully this helps someone.
And if you have any questions, feel free to ask.
I am using MAC OSX
I already follow the instruction on 0mq official site to install
when i compile it , i dont get any error.
But when i run the following command
java -classpath /Users/john/jzmq/ -cp $(lein classpath) storm.starter.WordCountTopology
I got the following error.
java.lang.UnsatisfiedLinkError: no jzmq in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1878)
at java.lang.Runtime.loadLibrary0(Runtime.java:849)
at java.lang.System.loadLibrary(System.java:1087)
at org.zeromq.ZMQ.<clinit>(ZMQ.java:34)
at storm.starter.spout.RandomSentenceSpout.nextTuple(RandomSentenceSpout.java:39)
at backtype.storm.daemon.executor$fn__3985$fn__3997$fn__4026.invoke(executor.clj:502)
at backtype.storm.util$async_loop$fn__465.invoke(util.clj:377)
at clojure.lang.AFn.run(AFn.java:24)
at java.lang.Thread.run(Thread.java:724)
My setting
$ echo $JAVA_HOME
/Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home
I also have zmq.jar under
/usr/local/lib and
/usr/local/share/java
I read through all the google search I can found. Still no crew why my one is not working
In addition to setting the JAR classpath, you need to specify where the jzmq .so library files reside. Did you build zmq, libzmq, and jzmq exactly as described in the directions? If so, you should see the .so library files in /usr/local/lib and zmq.jar in /usr/local/share/java, confirm that, then logout/login based on this, then try this:
java -Djava.library.path=/usr/local/lib -cp "/usr/local/share/java/zmq.jar:/Users/john/jzmq/<your jar here>" storm.starteer.WordCountTopology
Hope it helps
I am trying to build and run an example jni program. The program is just a sample helloworld program. I did not write it but I assume that it works. I am running this on Linux. There are four files.
HelloNative.c
HelloNative.h
HelloNative.java
HelloNativeTest.java
To build the files, I did
gcc -I/myDir/jdk/include -I/myDir/jdk/include/linux -fPIC -c HelloNative.c
gcc -shared -o HelloNative.so HelloNative.o
java *java
Here is the result of the build
HelloNative.c
HelloNative.h
HelloNative.o
HelloNativeTest.class
HelloNative.class
HelloNative.java
HelloNative.so
HelloNativeTest.java
Then I did
setenv LD_LIBRARY_PATH /myDir/myExample:${LD_LIBRARY_PATH}
java HelloNativeTest
I got the following error
Exception in thread "main" java.lang.UnsatisfiedLinkError: no HelloNative in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1734)
at java.lang.Runtime.loadLibrary0(Runtime.java:823)
at java.lang.System.loadLibrary(System.java:1028)
at HelloNative.<clinit>(HelloNative.java:9)
at HelloNativeTest.main(HelloNativeTest.java:8)
I checked the LD_LIBRARY_PATH and the HelloClassTest and HelloNative.so, they were all there. I tried to specify the -CLASSPATH also, but that did not seem to matter.
Does anyone have any ideas ?
Do the following, where X="HelloNative".
Give the library a filename following a system-dependent standard. On Linux, name your library libX.so.
Set the java.library.path System property to the directory containing your library.
Call System.loadLibrary("X") where "X" is the cross-platform part of the library name above.
You named your library HelloNative.so; change it to libHelloNative.so.
From http://download.oracle.com/javase/6/docs/technotes/guides/jni/spec/design.html#wp679:
The argument to System.loadLibrary is
a library name chosen arbitrarily by
the programmer. The system follows a
standard, but platform-specific,
approach to convert the library name
to a native library name. For example,
a Solaris system converts the name
pkg_Cls to libpkg_Cls.so, while a
Win32 system converts the same pkg_Cls
name to pkg_Cls.dll.
If you use OSGi in the future, there's an alternative to setting java.library.path.
You can also try by setting the java.library.path:
java -Djava.library.path=/myDir/myExample HelloNativeTest
Did you do a System.loadLibrary() from Java?
I am on Arch Linux, I just installed JRE and JDK and all the proper bin files (javac and java) are in /opt/java/bin/
I simply compiled a standard hello world, and compiled it with javac running javac ./hello.java and that made a class.
Now my problem is running it. I run java ./helloworld.class and it gives me an error, even if the file I point java to is non-existant:
Exception in thread "main" java.lang.NoClassDefFoundError: //helloworld/class
Caused by: java.lang.ClassNotFoundException: ..helloworld.class
(..omitted for clarity..)
Could not find the main class: ./helloworld.class. Program will exit.
You will notice the first line of the error, it munges the path //helloworld/class
When I feed java an absolute path, i.e java /home/foo/helloworld.class it gives the same error, but replaces the path's / with . in the first line, again munged.
What do you think is wrong? I really don't know why it is doing this..
When you run java, you just pass it the fully qualified class name (including package), not the file name.
java helloworld will look for helloworld.class.
java helloworld.class will look for helloworld/class.class
You do not run a file as
# java file.class
you run it as
# javac PATH/file.java
# java PATH/file
Do not add .class while using JAVA command.
Actually you should compile it like this
javac helloword.java
run the program
java helloword
And yet another thing: add command line option "-classpath ." or it short version "-cp .", i.e. your command line should look like:
java -cp . helloworld
this is if your class is in your current directory. Otherwise "." should be replaced by path where the class(es) may be found.