Creating JNI DLL on WinXP using MinGW and GCC

Question

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

Answer 1

Glad my post helped out at least a few people.
Believe it or not, I'm in the same boat now on Linux.
Atleast I know its the name mangling problem again. I
see a few symbols unmangled with nm, but most are,
and those are then one's JNI is complaining about
with UnsatisfiedLinkError.
So now I'm going through various post related to
linux and trying to find the same type of flag. The
"alias" flag doesn't work with RH4 g++ version
4.0.2.You should not need a flag on Linux. A typical compile for me on my Linux box is:
gcc -shared -o libjnitest.so -I/usr/java/jdk1.6.0_01/include -I/usr/java/jdk1.6.0_01/include/linux jnitest.c>
Window builds perfectly fine, but now I'm creating a
new platform target. Everything compiles and creates
the shared library, just can't get JNI to be happy.
BTW, my project: http://jnetpcap.sf.net
Ah. You have .cpp extensions on your filenames. Are you using gcc or g++ to compile? If you don't use g++, you can get errors such as:
undefined symbol: __gxx_personality_v0
Jim S.