studio - Cómo decirle a Android NDK que use una cadena de herramientas diferente
ndk r13 (3)
Bueno, simplemente puede agregar "NDK_TOOLCHAIN_VERSION = 4.9" en su Application.mk
He descargado una cadena de herramientas personalizada ( linaro ) para crear aplicaciones de Android basadas en ARM. ¿Cómo le digo al NDK que lo use? ¿Puedo definir o configurar algo en Android.mk y Application.mk que me permita hacerlo? ¿Hay otra manera?
El sistema de archivos make de NDK es bastante extensible y, de hecho, puede definir una cadena de herramientas diferente. Necesitarás cierta comprensión de cómo funciona Make.
Las build/core/init.mk de build/core/init.mk se descubren y se inicializan en la línea 261 de build/core/init.mk (en NDKr6, la línea # puede cambiar en futuras versiones). El código de inicialización busca archivos llamados config.mk debajo de $(NDK_ROOT)/toolchains/* . Por lo tanto, deberá agregar su cadena de herramientas en un subdirectorio bajo el directorio de cadenas de herramientas del NDK, y agregar un config.mk y setup.mk a ese subdirectorio. Mire toolchains/x86-4.4.3 y toolchains/arm-linux-androideabi-4.4.3 para ver ejemplos. Debería poder cortar y pegar la cadena de herramientas ARM config.mk y setup.mk si su cadena de herramientas tiene un diseño estándar.
Una vez que haya definido una cadena de herramientas en el directorio de la cadena de herramientas, puede cambiarla configurando la variable NDK_TOOLCHAIN dentro de su archivo Application.mk .
Como lo menciona la otra respuesta, las cadenas de herramientas son descubiertas por el sistema de archivos make de ndk-build en $(NDK_ROOT)/toolchains/ y puedes reflejar las ideas que ves allí. Pero hay algunos conceptos adicionales para el soporte de plataformas de destino que no son de Android que son interesantes, aunque pueden estar desactualizados pronto, ya que ndk-build comienza a admitir explícitamente otras plataformas, como mingw targeting win32 (u otros compiladores de gcc que apuntan a linux simple) .
En config.mk :
TOOLCHAIN_ABIS := (list of ABIs that the toolchain supports)
Esta es una definición importante, ya que puede usar este nombre en su Application.mk para compilar utilizando la cadena de herramientas para un ABI particular. Uno de los beneficios de corromper el uso de esta definición, es que ndk-build puede construir simultáneamente para múltiples ABI. Siempre se supone que la plataforma es Android, pero si desea apuntar a win32 usando una cadena de herramientas basada en mingw, puede definir un "ABI" como x86-win32 , y luego usar este ABI en su Application.mk para seleccionarlo como un complemento adicional. target a través de APP_ABI:= x86-win32 Luego, en sus archivos de Android.mk puede usar la definición TARGET_ARCH_ABI para seleccionar fuentes específicas de win32 e incluir rutas, por ejemplo:
ifeq ($(TARGET_ARCH_ABI),x86-win32)
LOCAL_SRC_FILES += my_win32_file.c
LOCAL_CFLAGS += -DSOME_WIN32_SPECIFIC
endif
La última pieza es que en setup.mk para su cadena de herramientas, puede ser insuficiente ver otras cadenas de herramientas como ejemplos, porque lo que setup.mk para una cadena de herramientas en particular realmente hace es anular la configuración de compilación en default-build-commands.mk , así que lo que quieres hacer es inspeccionar ese archivo y redefinir las cosas que no te gustan.
Siguiendo el ejemplo anterior, mingw no admite el indicador noexec en los archivos binarios, y puede deshacerse de esta función agregando las siguientes líneas en su setup.mk :
# These flags are used to enforce the NX (no execute) security feature in the
# generated machine code. This adds a special section to the generated shared
# libraries that instruct the Linux kernel to disable code execution from
# the stack and the heap.
TARGET_NO_EXECUTE_CFLAGS := # our platform doesn''t support this flag!
TARGET_NO_EXECUTE_LDFLAGS := # our platform doesn''t support this flag!
# These flags disable the above security feature
TARGET_DISABLE_NO_EXECUTE_CFLAGS := # our platform doesn''t support this flag!
TARGET_DISABLE_NO_EXECUTE_LDFLAGS := # our platform doesn''t support this flag!
Este es solo un ejemplo de las muchas características en default-build-commands.mk que deben ser anuladas, y por supuesto es importante proporcionar TOOLCHAIN_NAME para que la cadena de herramientas pueda seleccionarse a través de la variable NDK_TOOLCHAIN dentro de su archivo Application.mk además A la metodología ABI menciono anteriormente.