【问题标题】:Couldn't load libfoo: findLibrary returned null无法加载 libfoo:findLibrary 返回 null
【发布时间】:2012-08-08 20:32:04
【问题描述】:

我做的一切都“正确”:

  1. 在 jni/Android.mk 中使用 LOCAL_MODULE := libfoo 创建了我的 JNI 模块

  2. 致电System.loadlibrary("libfoo")

  3. 为方法声明了正确的签名,甚至用javah仔细检查了它

但仍然收到 UnsatisfiedLinkError 异常消息:

无法加载 libfoo:findLibrary 返回 null

【问题讨论】:

    标签: android android-ndk java-native-interface


    【解决方案1】:

    显然 loadLibrary 方法会自动添加“lib”,因此加载“libfoo.so”等文件名的正确方法是调用System.loadLibrary("foo")

    这点我学得很辛苦,所以你不必这样做。

    【讨论】:

    • 伙计,我希望这会上升到相关 Google 搜索的顶部。刚刚为我节省了几个(更多)小时!
    • maaan .. 非常感谢。这在某些 ndk 版本中是否已更改?完全疯狂的是我有一个库——需要另一个库。并且自动加载器无法满足依赖关系,因为它试图使用“libdependedfoo”加载。所以必须为“dependedfoo”添加一个加载。
    • @LassiKinnunen,您所说的无关紧要。依赖项未加载的原因不是因为某些“lib”前缀。在当前的 NDK 版本中,加载程序不会从应用程序的 lib 目录解析依赖项,您始终必须手动加载它们。甚至 NDK 的 docs/CPLUSPLUS.html 也会告诉您这样做。见code.google.com/p/android/issues/detail?id=34416
    • @Ilya 好的,我可能是错的,但我很确定我在控制台输出中看到加载器试图加载它所依赖的库而没有 lib 前缀(二进制文件中有名称)所以这可能是造成混乱的原因。
    • 上述问答是关于在库名称到达本机层之前添加到 Java 代码中的“lib”前缀(=仿生的 dlopen)。 Java 代码只是简单地执行“lib”+libName +“.so”并将这个字符串传递给 dlopen。然后 dlopen 打开这个库并尝试加载依赖项,而不添加“lib”或做任何其他有趣的事情。 (dlopen 加载你的 deps 的问题是——它的库路径不包括 your-app/lib,所以它永远无法自己找到它们)
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2014-10-10
    • 2012-12-02
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-04-23
    • 1970-01-01
    相关资源
    最近更新 更多