Link library name for JVM TI - java

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.

Related

iTextpdf Java compatibility

I need to encrypt a pdf document and decided to use itext Version 5.4.0 for this, and everything went well for my local test on my machine(with JAVA 1.8.0), but now I need to move the work to an oracle database 11gR2, and when I load the jar files (iText and bouncycastle) I keep getting the same error: ORA-29534:referenced object could not be resolved. I'm using the loadjava command for this:
loadjava -u SYSTEM/SYS_PWD#SID -o -r -v -f -noverify -synonym -g public itextpdf-5.1.0.jar
I've tried using SYS as well, but still getting the same error code.
I don't know if this has something to do with the JVM, the database uses JAVA 1.5.0.
I've searched about iText java requirements but couldn't found anything
useful, I'll be grateful with any help I can get.
I was able to upload, compile and use the libraries in the .jar files using the same command but with other parameter, and it compiled; the command I used is :
loadjava -u SYS/[pwd]#[SID] -r -v -f -genmissing -s -grant public [file].jar
Hope this can help someone in need out there!

How to set up JAssimp?

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.

JNI problems with a shared object

well i am having problems with jni, i am trying to run an example code
i have in one side
HelloJNI.java
and
javatoc_HelloJNI.h
and in the other side in c
HelloJNI.cpp
all is fine until I try to make the .so
it gives me this error.
**/usr/bin/ld: error: /tmp/cc2Udvjs.o: requires dynamic R_X86_64_32 reloc which may overflow at runtime; recompile with -fPIC**
so i am practically stuck in the creation of a .SO
Thanks for your help
You need to change your compile options to add the -fPIC flag.
gcc -fPIC -c cc2Udvjs.c
gcc -shared -o libWhatever.so cc2Udvjs.o
https://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?style=printable&part=1&chap=3

JNI: Problems compiling 64-bit native libraries

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..

rxtxSerial.dll for MacOS 10.8

I'm currently working on a ZigBee project and I'm programming on an Mac with Mountain Lion (10.8) and using Eclipse IDE. To use my Zigbee Module via USB for Serial communication, I need this rxtxSerial.dll. I only have a Windows compatible version right now.
Is somebody able to provide the necessary link to me?
Thank you!
Edit2
With all the latest updates as of 2012-11-15 (OSX 10.8.2) i needed to install glibtool via homebrew (http://mxcl.github.com/homebrew/) before I got the procedure below to work.
With homebrew installed and configured just do
brew install libtool
from a terminal.
Then proceed as described below.
/Edit2
Edit
So, I managed to compile it for my self on OS X Mountain Lion (10.8.2) and XCode (free from App Store).
Download rxtx-2.2pre2.zip and extract. Edit the "configure" file in the extracted directory and change the line that reads:
JAVAINCLUDEDIR=$JPATH/../../../Headers
to
JAVAINCLUDEDIR=/System/Library/Frameworks/JavaVM.framework/Versions/A/Headers
Then configure by doing
./configure
using a terminal in your working directory.
Now you will have a file named "Makefile" in your working directory, you need to edit the line in this file that reads:
LIBTOOLC = $(GLIBTOOL) --mode=compile $(CC) $(INCLUDES) $(CPPFLAGS) $(CFLAGS) $(VERBOSE_IOEXCEPTIONS) -c
to
LIBTOOLC = $(GLIBTOOL) --tag=CC --mode=compile $(CC) $(INCLUDES) $(CPPFLAGS) $(CFLAGS) $(VERBOSE_IOEXCEPTIONS) -c
And then run
make
You will now have RXTXcomm.jar in your working directory and librxtxSerial.jnilib in workingdirectory/i386-apple-darwin12.2.0
These are the files you need.
To work with them you may need to do
sudo mkdir /var/lock
sudo chmod 777 /var/lock
This approach worked for me.
PS. If you trust me you can get these files from here and here.
PPS. You may get:
WARNING: RXTX Version mismatch Jar version = RXTX-2.2-20081207
Cloudhopper Build rxtx.cloudhopper.net native lib Version =
RXTX-2.2pre2
But it should still work.
/Edit
I am also trying to use rxtx on ML and while I have not have any success yet I did find this link.
Java 6 and librxtxSerial.jnilib on Intel Mac OS X
And even though it says nothing about ML, one of the comments states that it works with Lion if you tweak it a little bit.
I'll report back if I get it to work here.

Categories

Resources