Primero una pequeña nota sobre la libc. La libc de Android es la libc Bionic (https://github.com/android/platform_bionic/) en lugar de la libc de GNU (glibc). Por lo tanto, la libc contenida en el NDK es Bionic, al igual que la libc disponible en dispositivos Android.
En lo que se refiere a glibc, es posible construirlo con el NDK. Sin embargo, su nombre chocará con la libc del sistema cuando esté instalado en dispositivos Android. Tenga en cuenta que esto es solo si va a construir una biblioteca dinámica. Si construye la libc de GNU como una biblioteca estática, entonces todo el problema anterior se soslaya, ya que nunca necesita instalar una biblioteca estática.
Ahora que responde a sus preguntas:
P1: Si usted está construyendo la glibc utilizando el NDK, entonces el Android.mk utiliza la variable BUILD_STATIC_LIBRARY para construir bibliotecas estáticas. Sin embargo, si no usa el NDK, entonces probablemente deba experimentar muchos dolores de cabeza (no sabe cuánto). No puedo contarte más sobre esto ya que no he intentado construir glibc, ya sea estático o dinámico. Además, parece que la vinculación estática con glibc es altamente desaconsejable, al menos para plataformas no móviles.
Desde el punto de vista de la ruptura, no hay diferencia entre los enlaces estáticos y dinámicos. Desde el punto de vista de la puesta en marcha, un ejecutable estático se inicia más rápido ya que el paso de carga de las bibliotecas dinámicas no es necesario. No hay penalización de memoria o velocidad de ejecución en ejecutables vinculados estáticos o dinámicos. El requisito de almacenamiento en disco es mayor para los ejecutables estáticos.
En cuanto a los problemas con la funcionalidad libc biónica falta, puede utilizar el método utilizado por la mayoría del software GNU, que es, proporcionar su propia implementación de una función en caso de que no se encuentra en las bibliotecas del sistema. He compilado el archivo-5.11, GNU make 3.82, diffutils-2.8 para Android pasando los toolchains NDK/includes/libs a autotools (./configure ...). Parece que estos programas contienen implementaciones de la mayor parte de la función de biblioteca no esencial, en caso de que las bibliotecas estándar no las proporcionen (en este caso, Bionic).
Nota: Intentaré construir un glibc estático y actualizaré la respuesta cuando tenga éxito/fallo.
No es solo el uso en el disco, también aumenta el uso en la memoria. Cuando vincula las bibliotecas jni de la aplicación Android con Bionic libc, hereda el acceso compartido de solo lectura a una copia que ya está en la memoria. –
¿Podría indicarme su fuente de información sobre esto? Quiero saber más, pero no puedo encontrar nada sobre esto. Sé que si las bibliotecas contienen datos, los datos no parecen estar compartidos entre los procesos, sin embargo, puede ser un caso de duplicación de copia de escritura de las páginas de memoria si el código de la biblioteca cambia sus variables de datos internas. – Samveen
Creo que ChrisStratton menciona: el caso de libc enlazado estáticamente. Cada proceso terminaría con su propia copia completa de TODAS las secciones de la misma biblioteca. Con la vinculación dinámica, tiene razón @Samveen – Tuxdude