I compiled a native DLL file on Windows (64-bit) with GCC flags -c and -o Name.dll.
When I did System.load("fullpahhere"), I get this error:
java.lang.UnsatisfiedLinkError: RenderControl.dll: %1 is not a valid Win32 application
If I recompile adding a blank main() method to the C source and removing the -c flag, it then fails with an UnsatisfiedLinkError that says it can't load a 32 bit DLL on a 64 bit machine.
Why is Java calling a DLL with no main method invalid? Doesn't that ruin the whole point of DLL files and the JNI?
Update
I fixed the main() issue. This GCC invocation setup works:
gcc -Wall -D_JNI_IMPLEMENTATION_ -Wl,--kill-at -I "C:\Program Files\Java\jdk1.6.0_32\include" -I "C:\Program Files\Java\jdk1.6.0_32\include\win32" -shared *.c -o lib.dll
I still need to figure out the JVM Architecture problem, however.
Where can I find a MinGW installation that is capable of compilnig 64 bit code? It seems my standard MinGW install only does 32 bit.
If I can get my hands on that, how do I decide which library to load in Java? Is there a System property that shows the JVM arch (NOT the OS arch)?
If you use the MinGW32 compiler, you cannot produce 64-bit code. This is something that is most likely intentional. Similar issues with other people I quickly looked up seem to suggest that you're trying to use a 32-bit native binary with 64-bit java.
Try compiling with mingw-w64 and see if that allays the problem.
There's also the possibility that your library simply isn't in the library path and that it's not being found even though you're giving System.load the full path, in which case you should make sure that your DLL is in the correct location for native libraries.
Check out http://tdm-gcc.tdragon.net/, to download TDM-GCC which gives an easy installation on Windows for MinGW-w64 referenced above. You can use the following code to generate a 64-bit dll after installint TDM-GCC.
"C:\MinGW64\bin\gcc.exe" -m64 -c -I"C:\Program Files\Java\jdk1.6.0_26\include" -I"C:\Program Files\Java\jdk1.6.0_26\include\win32" HelloWorld.c
It is the "-m64" which makes it 64 bit. This is run from the same directory as the HelloWorld.c C Code Source File. This generates the HelloWorld.o C Code Object File in the same directory as run..
Related
I have some c++ code which i use as shared library in a java application.My c++ code uses some libraries like ffmpeg and boost. and ffmpeg libraries in turn depend on libx264. my first question is - can i build my c++ into a "fat" shared library which contains all the symbols from all libraries used so that on a new machine if i just copy the fat .so file everything works.
If thats not possible then can you help me fix my current build process. This is what i am doing currently -
1)on a local VM(ubuntu 64) i compile ffmpeg code using -fPIC flag and install h264 and boost using apt-get commands.
2) on the same VM i compile my code using make file which looks like this-
INCLUDES = -I/opt/ffmpeg/include -I/usr/lib/jvm/java-7-openjdk- amd64/include -I/usr/lib/jvm/java-7-openjdk-amd64/include/linux
LDFLAGS = -L/home/ubuntu/ffmpeg_shared
LIBRARIES = -lavformat -lavcodec -lswscale -lavutil -lpthread -lx264 -lboost_system -lboost_thread -lboost_chrono
CC = g++ -std=c++11 -fPIC
all:clean final
final:Api.o ImageSequence.o OverlayAnimation.o Utils.o ImageFrame.o
$(CC) -o final.so Api.o ImageSequence.o OverlayAnimation.o Utils.o ImageFrame.o $(LDFLAGS) $(LIBRARIES) -shared
3) on a new machine where java app will run. i install h264 and boost using apt-get commands and copy ffmpeg's compiled library files to /usr/local/lib.
4) copy the final.so file to this new machine. but when the java code tries to use the final.so file i see it tries to use wierdly named files. for example - it tries to find libavcodec.so.57 , libavformat.so.57 etc. to fix this i just created a copy of these files ie libavcodec.so copied to libavcodec.so.57.
5)But these ffmpeg libraries in turn uses a differently named lib264.so file. on my new machine the apt-get command for x264 installed a file named libx264.so.148 but one of ffmpeg libraries is searching for file libx264.so.142 even if i rename this libx264.so file i get new errors where ffmpeg libraries tries to call libx264's methods which has these numbers attached.
6) at this time the only working option for me is to bring the c++ code on every new machine and build final.so file locally. this is something i want to avoid since i want to distribute the .so file along with jar file to my clients which they can easily use without having to build and install stuff.
I may have a solution for a 'fat' library, but I'm not 100% sure if it will work.
In general, it is possible to link together static libraries into a shared library by specifying these linker flags.
g++ -Wl,--whole-archive some_static_lib.a -Wl,--no-whole-archive
Therefore you would have to compile all your libraries into static libraries. If you think it's worth the effort to do this, you can give it a try.
To the second part:
It seems that your other machine is using different versions of the libraries. In example libx264.so.148 might be reffering to version 1.4.8 or something like that.
Therefore your libx264.so should be a symbolic link to libx264.so.148. You can verify that with
ln -l
to visualize, where your symbolic link is reffering to.
I recommend to manually compile all needed libraries on both machines. Then these problems should be solved.
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 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.
I am trying to write a JVM TI sample agent on Mac OS X. I have Java 5 installed. I want to know against which dynamic library should I link my sample agent code?
There's no need to link against anything.
gcc -I/path/to/java/include -shared -fPIC -o libagent.so agent.c
It's libjvm.so on Linux, so I suspect something similar on the Mac.
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?