The Artima Developer Community
Sponsored Link

Java Buzz Forum
JNI FAQ: UnsatisfiedLinkError

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Weiqi Gao

Posts: 1808
Nickname: weiqigao
Registered: Jun, 2003

Weiqi Gao is a Java programmer.
JNI FAQ: UnsatisfiedLinkError Posted: Jun 5, 2008 8:42 AM
Reply to this message Reply

This post originated from an RSS feed registered with Java Buzz by Weiqi Gao.
Original Post: JNI FAQ: UnsatisfiedLinkError
Feed Title: Weiqi Gao's Weblog
Feed URL: http://www.weiqigao.com/blog/rss.xml
Feed Description: Sharing My Experience...
Latest Java Buzz Posts
Latest Java Buzz Posts by Weiqi Gao
Latest Posts From Weiqi Gao's Weblog

Advertisement

I was asked questions similar to the following one quite a few times recently:

[weiqi@gao] $ java Main
Exception in thread "main" java.lang.UnsatisfiedLinkError: no Foo in java.librar
y.path
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1682)
        at java.lang.Runtime.loadLibrary0(Runtime.java:823)
        at java.lang.System.loadLibrary(System.java:1030)
        at Foo.(Foo.java:3)
        at Main.main(Main.java:3)

This question is most prone to be asked by C++ programmers working in a hybrid C++/JNI/Java environment, usually prefixed with "I'm trying to run our test suite, but am getting the following error. Any ideas?"

Here's my response in a email yesterday, posted here through the "Pull email response up to blog entry" refactoring pattern (the answer is Linux specific, but can be translated to other OSes with minimal effort):

This is the part that trips up people all the time. Look at it this way:

  1. Your Main class uses the Foo class
  2. The Foo class uses the libFoo.so JNI glue library. Foo probably looks like this:
    public class Foo {
        static {
          System.loadLibrary("Foo");
        }
        // ...
      }
  3. The libFoo.so JNI glue library uses underlying C++ *.so libraries

The manner through which java searches for the needed files are different in each scenario:

  1. Java searches for *.class files through the "-cp"/"-classpath" command line switch. If neither are specified on the command line, $CLASSPATH is searched
  2. Java searches for JNI glue *.so files through the "-Djava.library.path" command line switch. If "-Djava.library.path" is not specified, $LD_LIBRARY_PATH is searched, but the /etc/ld.so.conf mechanism is not used
  3. The way a JNI glue library searches for the underlying C++ *.so libraries is not controlled by the Java process at all. This is just a case where one *.so library is linked to other *.so libraries. The normal operating system rules apply ($LD_LIBRARY_PATH, /etc/ld.so.conf, etc.)

So you need "-Djava.library.path=...:/path/to/dir-of-libFoo:..." on your java command line. Or add /path/to/dir-of-libFoo to your $LD_LIBRARY_PATH.

As you can see, it's quite a long winded explanation (like a lot of things Java). And even this is not the most thorough. The key insight is the jump from the highlighted part of the stack trace to the corresponding conclusion #2.

Read: JNI FAQ: UnsatisfiedLinkError

Topic: Long Bet: XMPP Gears Previous Topic   Next Topic Topic: World Domination

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use