Android静态链接与dynamic链接对glibc

我一直在向Android交叉编译一些Linux工具(以及一些我自己的C代码),我面临的一个挑战是Android的libc有一些丢失/剥离的组件,最后修补我的代码以使其工作Android的libc(例如像这样的问题http://credentiality2.blogspot.com/2010/08/compile-ncurses-for-android.html )

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

问题2:对于Android的二进制文件静态链接glibc是一个好主意吗? 如果我开始静态链接,我应该期望什么破? 有没有任何性能/内存问题?

我理解静态和dynamic链接的大部分优缺点 – C ++应用程序 – 我应该使用静态链接还是dynamic链接库? 和静态链接vsdynamic链接

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

Solutions Collecting From Web of "Android静态链接与dynamic链接对glibc"

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

就glibc而言,可以用NDK来构build它。 但是,它的名称将与安装在Android设备上的系统libc冲突。 请注意,这只有当你去build立一个dynamic库。 如果您将GNU libc构build为一个静态库,那么上面的整个问题都会被回避,因为您永远不需要安装静态库。

现在回答你的问题:

  1. Q1:如果您使用NDK构buildglibc,则Android.mk使用variablesBUILD_STATIC_LIBRARY构build静态库。 但是,如果你不使用NDK,那么你可能需要进入很多头痛(不知道有多less)。 我不能告诉你更多关于这个,因为我还没有尝试过构buildglibc,无论是静态的还是dynamic的。 此外,似乎与glibc的静态链接是非常不鼓励的,至less对于非移动平台。

  2. 从破坏的angular度来看,静态链接和dynamic链接没有区别。 从开始的angular度来看,静态可执行文件启动速度更快,因为不需要dynamic库加载步骤。 在静态或dynamic链接的可执行文件中没有内存或执行速度的损失。 对于静态可执行文件,磁盘存储需求较大。

至于仿生libc缺失function的问题,您可以使用大多数GNU软件所使用的方法,即在系统库中缺less该function的情况下,提供您自己的函数实现。 我编译了5.11,GNU make 3.82,diffutils-2.8 for Android,将NDK工具链/ includes / libs传递给autotools(./configure …)。 似乎这些程序包含大部分非核心库函数的实现,以防标准库不提供它们(在这种情况下是Bionic)。

注意:我将尝试构build一个静态glibc,并在成功/失败时更新答案。

如果你打算使用glibc而不是仿生的,那么可以考虑使用(兼容内核代)arm-linux distro的工具链,而不是ndk。 如果您正在生成命令行可执行文件,这尤其如此。 (人们已经通过实验将Android设备上的chroot debian环境一路推回到G1)

对于一个jni子版(它仍然是本机应用程序代码的唯一正式认可的工具),它可能会与工具链有点“有趣”,因为您将运行在已经映射的进程中,并正在使用仿生libc支持Dalvik虚拟机。 大概如果你静态链接图书馆自己的依赖关系,你不会遇到名称冲突,但我希望你select的任何path将是一个关于内部工作的学习经验 – 不一定是坏事。

你必须有ncurses? 我用ndk成功地为android构build了curses。 还要考虑一下,如果程序严重地利用了这个function(例如,你真的在​​做大量的文本格式化吗?),还是只是把它用在一些小东西上,因为它被假定在目标系统上可用?