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

Discussion in 'Java' started by cppaddict, May 20, 2005.

  1. cppaddict

    cppaddict Guest

    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
    cppaddict, May 20, 2005
    #1
    1. Advertising

  2. 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
    Gordon Beaton, May 20, 2005
    #2
    1. Advertising

  3. cppaddict

    cppaddict Guest

    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
    cppaddict, May 20, 2005
    #3
  4. cppaddict

    cppaddict Guest

    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
    cppaddict, May 20, 2005
    #4
  5. 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
    Gordon Beaton, May 20, 2005
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mark
    Replies:
    9
    Views:
    701
    Steve W. Jackson
    Jan 16, 2004
  2. allelopath
    Replies:
    1
    Views:
    7,295
    P. Barthelemy
    Jan 4, 2005
  3. Replies:
    1
    Views:
    22,249
    Kari Ikonen
    Feb 6, 2005
  4. Dag Sunde
    Replies:
    8
    Views:
    2,638
    Dag Sunde
    Jan 5, 2007
  5. Ten Blade
    Replies:
    5
    Views:
    897
    Roedy Green
    Jul 16, 2011
Loading...

Share This Page