Ohh man, I spent entire day fighting with "UnsatisfiedLinkError "while trying to cal my native method. After reading all the posts with similar problems, and checking for every little thing that was suggested I figured it out. So I'm reposting the solution here since no one else had suggested this.
The solution to my problem was that g++/gcc compiler needed an option "-Wl,--add-stdcall-alias". This was the killer. I had the "-shared", but it wouldn't link without the "-Wl,--add-stdcall-alias" option!!!
As a summary, while its fresh in my mind, here are the trouble shooting steps I used:
1) Check package names and the generated .h file using javah. I checked and rechecked the names, even created simpler static void method to try and get it to link.
2) Make sure to use the "jobject" parameter for dynamic methods and "jclass" for static methods in the signature as second argument.
3) That method name starts with "Java_" and I stress the CAPITAL "J", can not be lowercase. Although if you are using javah, that should not be the problem, since javah can not ommit this kind of detail. The only thing that you need to check for is that if you change method from dynamic to static, and don't rerun the javah, or javah doesn't replace the previous file. So make sure you restart clean and that javah regenerated the file with "jclass" or "jobject" whichever is the case.
4) Used the "java -verbose:jni" debug flag to see my native method loaded. In my case when it wasn't working I couldn't see the method load, but there were no error messages from "System.loadLibrary" or from the verbose output. Only the UnsatisfiedLinkError. Frustrating. After the fix it loads perfectly:
[Dynamic-linking native method org.jnetpcap.Pcap.openVoid ... JNI]
5) I used "nm" found at "c:/MinGW/bin/nm.exe" to dump the symbol table, and I could see all my methods, with the appropriate named marked as text (T) flag. They were not being loaded when viewed using "java -verbose:jni" though.
6) I put "extern "C" {}" around all my JNI C++ methods.
7) Tried a gazilion other gcc options, posted in various messages, none worked.
8) Finally came accross the "-Wl,--add-stdcall-alias" flag which fixed it.
Here is a portion of my Makefile for reference:
$(LINK_TARGET) : $(OBJS)
g++ \
-shared \
-Wl,--add-stdcall-alias \
-o $@ $^ \
$(LIBDIRS) $(LIBS)
LIBDIR and LIBS point to a single external library dependency.
My IDE environment is Eclipse 3.2, but I run everything from Makefiles as external programs.
I wish this was documented somewhere, would have saved me an entire day of troubleshooting.
Cheers,
mark...
Message was edited by:
voytechs - added CODE tags