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

 

 

So how about telling us what that g++/gcc option means?

 

 

Well you saved me a day of troubleshooting! I was having a similar problem and your solution fixed it. This is the only place that I have seen this solution so I agree it should be documented somewhere. Thanks alot.

 

 

adding -Wl,--add-stdcall-alias saved us too... thanks! Jim

Message was edited by:
HandsOGold

 

 

The GCC compiler exports function names in shared libraries with a suffix indicating the number of bytes required to hold the arguments passed to the function. This is known as name mangling. So, a simple JNI method that takes no arguments would have an exported name that looks like this:

Java_somepackage_SomeClass_someNativeMethod@8

The @8 represents two 4 byte arguments (the JNIEnv pointer and the jobject or jclass for the method).

A one argument native method might have @12.

The '--add-stdcall-alias' option adds an additional entry for each method to the exported names in the shared library. This entry is an alias for the original entry and has the @xx stripped off.

The Java VM expects unmangled names.

Jim S.

 

 

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.

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

 

 

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

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.

 

 

For MinGW:
Instead of -Wl,--add-stdcall-alias you can compile C/C++ code using __cdecl convention. It will not mangle names this way (for some more info look here: http://www.willus.com/mingw/yongweiwu_stdcall.html).

For example:
JNIEXPORT void __cdecl Java_SuperClass_MakeSomething (JNIEnv *, jobject);

Or you can just redefine JNICALL either in your project or even globally in "jni_md.h".

Another solution would be to use a .DEF file when building DLL.

 

 

flag

-Wl,--kill-at

is also solution ( http://www.mingw.org/mingwfaq.shtml#faq-jni-dll )

Maybe this could help you on linux?

 

 

Thanks all you guys, iit solved my problems too.

 

 

Thank you so much for your solution!