我一直在将一些Linux工具(以及我自己的一些C代码(交叉编译到Android上，我面临的挑战之一是Android的libc有一些缺失/剥离的组件，我最终修补了我的代码以使其与Android的libc一起工作(例如，像这样的问题 http://credentiality2.blogspot.com/2010/08/compile-ncurses-for-android.html(
Q1 ： 如何在与 arm 工具链(或 ndk-build(交叉编译的同时对 glibc(和其他依赖项(进行静态链接？
Q2 ： 静态链接 glibc for Android 二进制文件是个好主意吗？如果我开始静态链接，我应该期望任何东西会中断吗？是否存在任何性能/内存问题？
我从这里了解静态与动态链接的大部分优缺点 -C++应用程序 - 我应该对库使用静态链接还是动态链接？和静态链接与动态链接
所以我想知道在交叉编译二进制文件时我是否应该静态链接 Android 的 glibc。
首先是关于libc的小注释。Android libc 是 Bionic libc (https://github.com/android/platform_bionic/(，而不是 GNU libc (glibc(。因此，NDK 中包含的 libc 是仿生的，安卓设备上可用的 libc 也是如此。
就glibc而言，可以使用NDK构建它。但是，当安装在安卓设备上时，它的名称将与系统 libc 冲突。请注意，这仅在您构建动态库时才适用。如果你把 GNU libc 构建为一个静态库，那么上面的整个问题就会被回避，因为你永远不需要安装一个静态库。
现在回答您的问题：
-
问题 1：如果您使用 NDK 构建 glibc，则 Android.mk 使用变量BUILD_STATIC_LIBRARY来构建静态库。但是，如果您不使用 NDK，那么您可能需要陷入很多头痛(不知道有多少(。我不能告诉你更多关于这一点，因为我还没有尝试过 glibc 的构建，无论是静态的还是动态的。此外，似乎强烈建议不要使用glibc进行静态链接，至少对于非移动平台而言。
-
从中断的角度来看，静态链接和动态链接之间没有区别。从启动的角度来看，静态可执行文件启动得更快，因为不需要动态库加载步骤。静态或动态链接可执行文件中没有内存或执行速度损失。静态可执行文件的磁盘存储要求更大。
至于仿生libc缺少功能的问题，你可以使用大多数GNU软件使用的方法，即提供你自己的函数实现，以防系统库中缺少它。我已经编译了file-5.11，GNU make 3.82，diffutils-2.8 for Android将NDK工具链/包含/库传递给autotools(./configure ...(。似乎这些程序包含大多数非核心库函数的实现，以防标准库不提供它们(在本例中为 Bionic(。
注意：我将尝试构建一个静态 glibc，并在成功/失败时更新答案。
如果你打算使用 glibc 而不是仿生，可能值得考虑使用(兼容的内核生成(arm-linux 发行版的工具链而不是 ndk。 如果要生成命令行可执行文件，则尤其如此。 (人们已经实验性地将 android 设备上的 chroot debian 环境一直推回了 G1(
对于 jni sub(它仍然是唯一官方认可的原生应用程序代码工具(，使用任一工具链都可能会变得有点"有趣"，因为您将在一个已经映射并持续使用仿生 libc 来支持 Dalvik VM 的进程中运行。 大概如果你静态地链接库自己的依赖项，你不会遇到名称冲突，但我希望无论你选择什么路径，这都将是关于内部工作的学习体验 - 并不是说这必然是一件坏事。
你一定要有诅咒吗？ 我曾经用 ndk 成功地为 android 构建了诅咒。 还要考虑程序是否正在认真利用它(即，你实际上是在做大量的文本格式化吗？(，或者只是把它用于一些小事情，因为它被认为在目标系统上可用？