JNI Unsatisfied Link Error (but the method name is correct!)
 

When I've gotten unsatisfied link errors before when calling native
methods, it's usually been because the mathod name had been changed in
the Java file, but not updated in the JNI header (and the DLL
recompiled using the new header).

This time, though, the names seemed to be correct.

My java method (part of the Engine class in the package blackjack)
looks like:

public native void init(String windowTitle);

My C JNI method stub look like:

JNIEXPORT void JNICALL Java_blackjack_Engine_init(JNIEnv *, jobject,
jstring);

The DLL compiles without error, and is being loaded without error (in
a static block). What else could be causing the unsatisifed link
error?

TIA,
cpp

Re: JNI Unsatisfied Link Error (but the method name is correct!)
 

On Fri, 20 May 2005 01:07:44 GMT, cppaddict wrote:
> My java method (part of the Engine class in the package blackjack)
> looks like:
>
> public native void init(String windowTitle);
>
> My C JNI method stub look like:
>
> JNIEXPORT void JNICALL Java_blackjack_Engine_init(JNIEnv *, jobject,
> jstring);
>
> The DLL compiles without error, and is being loaded without error
> (in a static block). What else could be causing the unsatisifed link
> error?

There are two things that cause UnsatisfiedLinkError. One is when
System.loadLibrary() fails to load the library, the other is when the
JVM fails to find a specific method in the library. The text of the
error message itself will indicate which is the case, but you've
already indicated that the library loads ok.

The JVM will fail to find a method in the library for various reasons,
but essentially they all point to the same thing: that a method with
the specified name was not found. Realize that the compiler itself
sometimes does things with the symbol names unless you tell it not to,
and this will prevent the JVM from finding the method, even though
you've named them correctly.

Examine the library contents, for example with objdump or nm (on unix)
or dumpbin or quickview (on windows) to see what's there.

Here are some things that can cause the symbols in the library to be
different from your source code:

- you are compiling with a C++ compiler, and it has mangled the symbol
names because you failed to declare your native methods with extern
"C". If you included the header file generated by javah (which you
should), and your signatures *exactly* match those in the header
file generated by javah (which they should), then then this has
already been done for you. If that isn't the case, why not?

- your compiler has added extra information to the symbol names such
as @8 or @12. There should be a compiler option to prevent that (for
gcc, try -Wl,--kill-at).

/gordon

--
[ do not email me copies of your followups ]
g o r d o n + n e w s @ b a l d e r 1 3 . s e

Re: JNI Unsatisfied Link Error (but the method name is correct!)
 

Gordon,

Thanks for your reply.

>Examine the library contents, for example with objdump or nm (on unix)
>or dumpbin or quickview (on windows) to see what's there.

Opening the .dll in depends.exe confirms that the names have been
mangled (or decorated), despite my using the javah generated header
file (which includes the extern C directive). Any idea why this is
happening? I compiled with Borland, and I have successfully used
Borland-compiled DLLs with JNI before. In any case, I cannot find any
compiler option do suppress the mangling, despite lots of google and
help searching.

Any other advice?

Thanks,
cpp

Re: JNI Unsatisfied Link Error (but the method name is correct!)
 

Gordon,

Just wanted to let you know that because of your post, I solved the
problem. It turned out I had forgotten to include the header file in
my implementation file, so that the extern C directive was never
appearing. Would never have noticed that if you hadn't narrowed down
the problem for me. Thank you very, very much.

cpp

Re: JNI Unsatisfied Link Error (but the method name is correct!)
 

On Fri, 20 May 2005 10:29:37 GMT, cppaddict wrote:
> Opening the .dll in depends.exe confirms that the names have been
> mangled (or decorated), despite my using the javah generated header
> file (which includes the extern C directive). Any idea why this is
> happening?

Why don't you post a real example of what the symbols look like in the
dll.

If you mean C++ decorated, it's because your methods don't exactly
match the declarations in the header file. You can declare the methods
themselves using extern "C" too, but the signatures really should
match the generated ones.

If you mean C decorated (@8, @12 etc), you could look for a linker
switch like --add-stdcall-alias, or define a link map to create
aliases for the symbols. Sorry I can't be more specific, I've never
programmed on windows and don't really know what is required. Maybe
someone who has can offer a concrete solution here.

Alternatively, you could call RegisterNatives() from JNI_OnLoad, which
lets you specify any names you like for the native methods. And since
you identify the methods by pointer, any name mangling should have no
effect.

/gordon

--
[ do not email me copies of your followups ]
g o r d o n + n e w s @ b a l d e r 1 3 . s e