Android 本机链接器需要专门名为 libjpeg.so.62 的文件答案

【问题标题】：Android native linker wants file named libjpeg.so.62 specificallyAndroid 本机链接器需要专门名为 libjpeg.so.62 的文件
【发布时间】：2014-08-20 02:22:43
【问题描述】：

我有一个使用 libjpeg-turbo 的 Android 应用程序的本机库。我正在使用 NDK 编译库和 libjpeg-turbo。一切似乎都可以正常编译和安装（我在手机上的 /data/data/com.company.app/lib 中看到所有 .so 文件），我正在打电话

System.loadLibrary("jpeg");
System.loadLibrary("zmq");
System.loadLibrary("MySuperLib");
System.loadLibrary("jnilibwrapper");

E/AndroidRuntime(8186)：java.lang.UnsatisfiedLinkError：dlopen 失败：无法加载“libjnilibrapper.so”所需的库“libMySuperLib.so”；导致无法加载所需的库“libjpeg.so.62” “libMySuperLib.so”；由找不到库“libjpeg.so.62”引起

我找到了这个解决方法，像这样创建库的符号链接让我通过了这个错误

root@klteatt:/data/data/com.company.app/lib # ln -s libjpeg.so libjpeg.so.62

但这当然不是解决方案。

我们哪里会出错？为什么它特别想要 libjpeg.so.62？

【问题讨论】：

“libMySuperLib.so”与“libjpeg.so.62”相关联。如果您使用ndk-build，这是非常不寻常的。但是，如果您将独立工具链与 Unix 风格的 makefile 一起使用，那么这样的结果就不会出乎意料。在后一种情况下，您可能需要对 make 文件或配置脚本进行一些编辑。
@AlexCohn 是的，我们使用的是 libjpeg-turbo 的自动工具，然后是标准的 makefile。我会让解决我们问题的同事提交详细的答案。谢谢！

标签： java android android-ndk loadlibrary libjpeg-turbo

【解决方案1】：

这个问题是由MySuperLib 在编译时与libjpeg-turbo 的版本化soname 链接引起的。 Android 的 JNI 运行时当前不支持版本化动态库，这就是它无法“找到”libjpeg.so 的原因，因为它只需要一个未版本化的 soname。

在没有版本信息的情况下编译libjpeg-turbo 的一种可能方法是修改libjpeg-turbo 的Makefile.am *LDFLAGS 变量，该变量传递给libtool。通过将*LDFLAGS 变量更改为包含libtool 的-avoid-version 标志，libtool 将尝试避免创建嵌入了版本信息的库。创建无版本共享库通常是一个可怕的想法，但由于此时您实际上无法在 Android 上“安装”共享库，因此它是相当安全的，因为您的 MySuperLib 库是唯一的将永远使用未版本化的libjpeg.so。

下面是libjpeg-turbo 的Makefile.am 的补丁示例，它将生成未版本化的 libjpeg.so：

--- Makefile.am 2014-08-28 09:57:37.000000000 -0700
+++ Makefile.am.patched 2014-08-28 09:57:20.000000000 -0700
@@ -1,5 +1,5 @@
 lib_LTLIBRARIES = libjpeg.la
-libjpeg_la_LDFLAGS = -version-info ${LIBTOOL_CURRENT}:${SO_MINOR_VERSION}:${SO_AGE} -no-undefined
+libjpeg_la_LDFLAGS = -avoid-version -no-undefined
 include_HEADERS = jerror.h jmorecfg.h jpeglib.h

 if WITH_TURBOJPEG

这里是 libtool 的链接模式手册的链接，了解更多选项和信息：http://www.gnu.org/software/libtool/manual/html_node/Link-mode.html

【讨论】：