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.
