Android NDK compiler option settings
In the Android NDK development, there are two important documents: Android.mk and Application.mk, fulfill their duties, how to guide the compiler to compiler, and decide what to compile results are. This article details several common NDK configuration options to help you understand the appropriate configuration options.
一、Application.mk
Application.mk is actually lightweight Makefile, usually in the $ PROJECT / jni directory, is used to configure all modules compiled variables, the following example:
APP_ABI := armeabi arm64-v8a x86_64 x86 armeabi-v7a
NDK_TOOLCHAIN_VERSION := clang3.5
APP_STL := stlport_static
APP_OPTIM = debug
1, APP_ABI (ABI target platform type)
NDK compilation, APP_ABI default selection armeabi ABI, may be provided by providing one or more ABI APP_ABI, a set table instruction corresponding to different APP_ABI.
Instrunction setValue
ARMv5TE based CPUAPP_ABI := armeabi
ARMv7 based CPUAPP_ABI := armeabi-v7a
ARMv8 AArch64APP_ABI: = arm64-v8a
IA-32APP_ABI: = x86
ıntel64app_ab of: = x86_64
MIPS32APP_ABI := mips
MIPS64(r6)APP_ABI := mips64
All supported instruction setsAPP_ABI := all
Table I: ABI Type
When developing APP_ABI selected according to the needs, to select the ABI view of efficiency and APK size. Default models support the case 64 of the 32-bit abi so, therefore the size of the relatively high demand; as armeabi-v7a instruction set compatible armeabi; x86 market compatibility for mobile phones, use libhoudini basic module, compatible instruction set arm , you can select only basic equipment available in the market compatible armeabi ABI, if slightly on the performance requirements, you can add x86 ABI.
2, NDK_TOOLCHAIN_VERSION (compiler type and version)
The default is to use GCC compiler, version GCC for selecting versions NDK relationship, I am using NDK R12, ABI is the default 64 bit ABI GCC 4.9,32 4.8 default GCC, of course, also possible in the above example as set forth, set clang compiler.
3, APP_STL (runtime type)
Android NDK default is minimal support for C ++ runtime library, if you want your program to use NDK STL, you can set APP_STL: = stlport_static, APP_STL there are several values in Table II.
NameExplanation
system (default) the default C ++ runtime library
sttport version stlport_static statically linked method used STL
sttport version stlport_shared way to dynamically link the use of STL
gnustl version gnustl_static statically linked method used STL
gnustl_shared dynamic link method used gnustl version of STL
gabi ++ _ static statically linked method used gabi ++
gabi ++ _ shared dynamic link method used gabi ++
c ++ _ static statically linked method used LLVM libc ++
c ++ _ shared dynamic link method used LLVM libc ++
Table II: NDK runtime
If there are a plurality of SO APK files used STL, recommended use dynamically linked STL, this can reduce the file size of the entire APK.
Also note that the official NDK runtime in addition to the default outside support RTTI and exceptions, however, is disabled by default, will explain how to open the following Android.mk in.
4, APP_OPTIM (compilation mode)
"Release" mode is the default, the generated binary optimized; may be set to "debug" mode, "debug" mode is not optimized binary generation, BUG offers many information to facilitate debugging and analysis.
There are other configuration options, are interested can see Application.mk official documents .
二、Android.mk
Android.mk is a lightweight Makefile, it will be C / C ++ source code into one module in the organization, module can be static libraries, shared libraries or stand-alone executable file, a file can have a Android.mk also be a plurality of module, there may be dependencies between modules.
1, the basic concept
Android.mk included NDK provides macros, variables, and modules described variables, assign these macros, variables, and variables together to form Android.mk file, which fulfill their duties in NDK compilation, guides compiled the NDK.
Macro: including my-dir, all-subdir-makefiles the like, is called by '$ (call)', returns the text information.
Variables include: CLEAR_VARS, BUILD_SHARED_LIBRARY, TARGET_ARCH, etc., provided by the NDK build system, and existed before Android.mk file is parsed. Android.mk files are likely to be repeatedly resolved, so the value of these variables are parsed each time may be different.
Module Description variables: Module-description, including LOCAL_PATH, LOCAL_MODULE, LOCAL_SRC_FILES other LOCAL_ prefix variables except LOCAL_PATH, are filled between statements include $ (CLEAR_VARS) and include $ (BUILD_XXX).
Other configurations can view Android.mk Android.mk official documents .
2, basis
Android.mk including some very basic variables, including the following basic variables chestnuts, I will explain in detail.
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := hello-jni
LOCAL_SRC_FILES := hello-jni.c
include $(BUILD_SHARED_LIBRARY)
LOCAL_PATH (the current directory)
LOCAL_PATH variables describing the module, must define a Android.mk LOCAL_PATH, used to locate the source file, in this example, using a compilation system macro "my-dir" ( "my-dir" return to last comprising the Makefile path, usually the current directory where Android.mk), used to return the current directory.
This variable will not be CLEAR_VARS cleared, so each file Android.mk only need to define it once.
CLEAR_VARS (variable Clear)
CLEAR_VARS system variables provided by the compiler, the name suggests, is to remove the module variable (between the include $ (CLEAR_VARS) and include $ (BUILD_XXX) of LOCAL_XXX module variable), except of course LOCAL_PATH. Since all control files are compiled GNU Make a single executable contexts resolved, and this in the context of all the variables are global, so it is necessary to clean up the corresponding variable before compiling module.
LOCAL_MODULE（module名称）
LOCAL_MODULE is a unique identifier Android.mk file module, the name must be unique and without spaces. By default, it determines the generated file names, such as "hello-jni" corresponding dynamic library name is libhello-jni.so, but when you want to index it, need "hello-jni" can also be variable by LOCAL_MODULE_FILENAME override this default name.
LOCAL_SRC_FILES (source files)
LOCAL_SRC_FILES variables include a list of C source files / C ++, the source files will be compiled into a module in, but do not have to list the header files and include file, the compiler will automatically play for you to find all the required dependencies. It is noted that the path of cis linux slash (/).
BUILD_SHARED_LIBRARY (dynamic library compilation)
BUILD_SHARED_LIBRARY are variables provided by the compiler, represents compiled DLL, it points to a GNU Makefile script that collects all the information from all the definitions of the variables after LOCAL_XXX include $ (CLEAR_VARS), the compiler decide what and how to compile.
There BUILD_STATIC_LIBRARY, and BUILD_SHARED_LIBRARY similar, represents compiled into a static library, static library is not copied to the APK.
PREBUILT_SHARED_LIBRARY (precompiled)
Point to a build script is used to specify a dynamic precompiled library. Using this variable, and unlike BUILD_SHARED_LIBRARY BUILD_STATIC_LIBRARY as LOCAL_SRC_FILES value must be only one path to precompiled dynamic library, such as foo / libfoo.so, instead of the source file. As chestnuts.
include $(CLEAR_VARS)
LOCAL_MODULE := test
LOCAL_SRC_FILES := lib/$(TARGET_ARCH_ABI)/libtest.so
include $(PREBUILT_SHARED_LIBRARY)
PREBUILD_STATIC_LIBRARY and PREBUILD_SHARED_LIBRARY, in that it is used to refer to a static library.
TARGET_ARCH_ABI (ABI target name)
As shown in Table I, the target name ABI. If more than one definition of ABI, each time you parse Android.mk, values are not the same, the main usage scenario is different fundamentally different ABI definitions files.
3, other modules variables LOCAL_LDLIBS (DLL)
Links for additional options, all libraries have "-l" prefix. A plurality of libraries can be also listed, separated by spaces, for example:
LOCAL_LDLIBS: = -llog -ldl
Android NDK a plurality of default link library, need not be displayed to the LOCAL_LDLIBS added, including the standard C libraries, the standard C ++ libraries, real-time extensions and pthread library. It also provides a number of libraries to be displayed to add these library version has a relationship, as shown in Table III.
Android levelLibExplanation
Android-3-llogAndroid Log
-lzZlib Compression Library
-ldlDynamic Linker Library
Android-4-lGLESv1_CMOpenGL ES 1.x Library
Android-5-lGLESv2OpenGL ES 2.0 Library
Android-8-ljnigraphicsThe jnigraphics Library
Android-9-lEGLThe EGL graphics library
-lOpenSLESOpen ES native audio Library
-landroidNatice Android API
Android-14-lOpenMAXALOpenMAX AL natice multimedia Library
Android-18-lGLESv3OpenGL ES 3.0 Library
Android-21-lGLESv3OpenGL ES 3.1 Library
Table 3: Link Library
LOCAL_CFLAGS, LOCAL_CPPFLAGS and LOCAL_LDFLAGS (compiler, linker flags)
LOCAL_CFLAGS is defined when compiling C / C ++, compiler flags passed to the collection, LOCAL_CPPFLAGS only supports C ++, but also the role of some of the information passed to the compiler, LOCAL_LDFLAGS passed to the connector means some additional parameters.
In NDK development will inevitably use these flags, especially when optimizing compiler, the following compiler options I encountered in development.
① LOCAL_CPPFLAGS += -fexceptions
Since the beginning of NDK compiled from R5 only support C ++ exception control, for versatility, exception handling is disabled by default (-fno-exceptions), it is necessary to add LOCAL_CPPFLAGS in the specified module in + = -fexceptions compiler option can compile with exception handling C ++ code. APP_CPPFLAGS may be arranged directly in Application.mk + = -fexceptions.
② LOCAL_CPPFLAGS += -frtti
NDK R5 from the beginning, NDK also began to support C ++ RTTI, but for versatility, all the C ++ source files when they were built by default does not support the RTTI (-fno-rtti), by adding Android.mk in: LOCAL_CPPFLAGS + = -frtti add APP_CPPFLAGS + = -frtti RTTI to turn in Application.mk.
③ LOCAL_CFLAGS += -fvisibility=hidden
In NDK development, the function of the source file has a default visibility attribute is public, so the compiler-generated files in almost all the function names, global variable names are derived, in fact only need to export at the beginning of java_com jni function can be, other functions do not need to be exposed, set LOCAL_CFLAGS + = -fvisibility = Android.mk in the hidden, you can hide functions do not need to export, if a function needs to be exported, then add JNIEXPORT or __attribute__ ((visibility ( "default" ))) can be.
In addition to safety, do not export function unnecessary, but also can reduce the volume so.
④ LOCAL_CFLAGS += -ffunction-sections
When this parameter is not added, the compiled code portion .o file only .text section, using this parameter, each function will have a separate segment, For chestnut, the function func1 () .text.func1 compiled into segments, although segment more, but the link does not affect the size of the code.
⑤ LOCAL_CFLAGS += -fdata-sections
Ibid., Each has a separate data segment.
⑥ LOCAL_LDFLAGS += -Wl --gc-sections
-Wl, option tells the compiler to pass options to the back of the connector, -Wl, - gc-sections do not mean to use the Delete link connector ld segment. The use LOCAL_CFLAGS + = -ffunction-sections -fdata-sections, then the code and data is divided into different segments, any function call or if the data is not a function, the function is not called ld not be linked, thus so the file size is reduced, so the purpose of optimization.
⑦ LOCAL_LDFLAGS += -fPIC
PIC (position independent code) for compiling position independent code, position-independent code can be used to generate a shared library. When you do not add -fPIC, the code segment .so file is loaded, the data object referenced in the snippet needs relocation, the relocation will modify the code segment content, thus leading to not use this .so, the process in the kernel code segment it will generate a copy of this document.
⑧ LOCAL_LDFLAGS += -Wall
This means wring all the meaning of all warning messages during the compilation and linking process.
⑨ Other
If you need to learn about other compiler flags, you can view the GCC Command Options document .
NetEase cloud catch - Netease's most professional quality tracking platform APP