4

假设我们正在构建一个共享库 A，它需要链接到 2 个外部静态库 B 和 C。您所拥有的只是 libB.a 和 libC.a，以及它们的头文件。

这是 libA 的简化 Android.mk：

LOCAL_LDLIBS := ../external/libB.a ../external/libC.a

include $(BUILD_SHARED_LIBRARY)

AFAIK，共享库的链接方式是：

  1. 获取 B 和 C 的所有目标文件
  2. 去掉 A 没有引用的目标文件
  3. 解析 B 和 C 中的引用

这会导致链接错误，因为 B 和 C 相互调用，特别是它们调用在步骤 2 中被剥离的函数，因为 A 没有调用它们。

如果我们自己构建静态库，那么只需将 LOCAL_STATIC_LIBRARIES 替换为 LOCAL_WHOLE_STATIC_LIBRARIES，这可以防止代码剥离（以牺牲代码大小为代价）。在引擎盖下，它将 --whole-archive 传递给链接器。

由于我们没有构建 B 和 C（甚至没有重建它们的源代码），有哪些选择？

  1. 手动引用 A 中缺少的函数，以免它们被剥离
  2. 弄清楚如何将 --whole-archive 传递给外部静态库的链接器
  3. 使用 PREBUILT_STATIC_LIBRARY （看到它提到，但从未使用过它，根据文档，它在这种情况下听起来不适用）
  4. 构建可执行文件而不是共享库（不会以相同的方式剥离代码）
  5. 移动/重命名外部库以欺骗 NDK 构建系统认为它们是我的，以便我可以将它们添加到 LOCAL_WHOLE_STATIC_LIBRARIES。

我选择了选项 1，因为它是第一个有效的方法，但显然它不是很好。我在问是否有更好的解决方案。

这个问题的答案（Linking issue when prebuilt static and shared libraries with the Android NDK）让我想知道我是否需要重新评估我的构建设置（共享库链接到外部静态库）。我无法在那里发表评论，所以我在这里问了我自己的问题。

4

1 回答 1

6

答案可以在如何使用 binutils 链接器处理静态库之间的递归依赖关系？.

LOCAL_LDLIBS := -L ../external/ -lB -lC -lB

我采用了两个库的 NDK 示例，并进行了最小的更改以在 GitHub 上演示该技术。

更新（2017）：自2012年以来，NDK的规则变得更加严格，现在它会抱怨LOCAL_LDLIBS包含非系统库：

Android NDK：警告：Android.module：链接器标志中的非系统库：-la -lb
Android NDK：这可能会导致构建不正确。尝试使用 LOCAL_STATIC_LIBRARIES
Android NDK: 或 LOCAL_SHARED_LIBRARIES 来列出
Android NDK: current module 的库依赖项

这只是一个警告，因此您可以忽略它。

或者在后面添加空间-l以超越 NDK 保护：

LOCAL_LDLIBS := -L ../external/ -l B -l C -l B

或者，您可以使用

LOCAL_LDLIBS += -L ../external -Wl,--start-group -l B -l C -Wl,--end-group

如果所涉及的库不是预构建的，则无需猜测它们的位置（这在使用 Android Studio NDK 集成时可能特别棘手）。采用

LOCAL_LDLIBS := -L $(TARGET_OUT) …

存在一种替代方法，它不使用“递归”链接。但它涉及迭代。首先，尝试以通常的方式构建您的共享库。如果此操作因未解析的符号而失败，请将所有这些符号复制到剪贴板，并将它们粘贴到您的Android.mk中。假设这些符号是extBa,extBb和extBc(在上面的场景中，我相信libC的某些对象没有找到这些在libB某处定义的符号，这就是链接失败的原因)。您现在需要的，添加

LOCAL_LDFLAGS += -Wl,-u'extBa' -Wl,-u'extBb' -Wl,-u'extBc'

您可以进行下一步，并将这一切与libC捆绑在一起：

LOCAL_EXPORT_LDFLAGS += -Wl,-u'extBa' -Wl,-u'extBb' -Wl,-u'extBc'

现在任何使用libC的共享库都不会错过这些符号。

于 2012-12-02T10:23:17.223 回答