针对 glibc 的 Android 静态链接与动态链接

Question

我一直在将一些 Linux 工具(和我自己的一些 C 代码)交叉编译到 Android，我面临的挑战之一是 Android 的 libc 有一些缺失/剥离的组件，我最终修补了我的代码以制作它与 Android 的 libc 一起工作(例如像这样的问题 http://credentiality2.blogspot.com/2010/08/compile-ncurses-for-android.html )

问题 1:在使用 arm 工具链(或 ndk-build)进行交叉编译时，如何静态链接 glibc(和其他依赖项)？

问题 2:为 Android 二进制文件静态链接 glibc 是个好主意吗？如果我开始静态链接，我是否应该期望有什么中断？有任何性能/内存问题吗？

我从这里了解静态链接与动态链接的大部分优缺点 - C++ application - should I use static or dynamic linking for the libraries?和 Static linking vs dynamic linking

所以我想知道在交叉编译二进制文件时是否应该为 Android 静态链接 glibc。

Answer 1

首先是关于 libc 的一个小说明。 Android libc 是 Bionic libc ( https://github.com/android/platform_bionic/ ) 而不是 GNU libc (glibc)。因此，NDK 中包含的 libc 是仿生的，就像 android 设备上可用的 libc 一样。

就 glibc 而言，可以使用 NDK 构建它。但是，当安装在安卓设备上时，它的名字会与系统libc冲突。请注意，这仅适用于构建动态库的情况。如果您将 GNU libc 构建为静态库，那么上面的整个问题就被回避了，因为您永远不需要安装静态库。

现在回答你的问题:

1. 问题 1:如果您使用 NDK 构建 glibc，则 Android.mk 使用变量 BUILD_STATIC_LIBRARY 构建静态库。但是，如果你不使用 NDK，那么你可能需要陷入很多头痛(不知道有多少)。由于我还没有尝试构建 glibc，无论是静态的还是动态的，我都无法告诉您更多信息。此外，似乎非常不鼓励使用 glibc 进行静态链接，至少对于非移动平台而言。

2. 从中断的角度来看，静态链接和动态链接之间没有区别。从启动的角度来看，静态可执行文件启动速度更快，因为不需要动态库加载步骤。在静态或动态链接的可执行文件中没有内存或执行速度损失。静态可执行文件的磁盘存储要求更大。

至于 bionic libc 缺少功能的问题，您可以使用大多数 GNU 软件使用的方法，即提供您自己的功能实现，以防系统库中缺少该功能。我已经为 Android 编译了 file-5.11、GNU make 3.82、diffutils-2.8，将 NDK 工具链/includes/libs 传递给 autotools (./configure ...)。这些程序似乎包含大多数非核心库函数的实现，以防标准库不提供它们(在本例中为 Bionic)。

注意:我会尝试构建静态 glibc，并在成功/失败时更新答案。