This article is another article in my "Android NDK Development" series, in which I shared a android.mk sample template that automatically adds a list of source files so that you can quickly build a complete NDK development Engineering framework, and this article explores several major NDK The configuration of the compilation options, including: App_abi, Local_ldlibs, Local_cflags, App_stl, so that you are no longer looking at the NDK's compilation parameters.
1. Overview
First review the respective responsibilities of ANDROID.MK and application.mk in the development of Android NDK.
ANDROID.MK, responsible for configuring the following:
(1) Module name (local_module)
(2) source files (local_src_files) that need to be compiled
(3) Dependent third-party libraries (local_static_libraries,local_shared_libraries)
(4) Compile/Link options (local_ldlibs, Local_cflags)
APPLICATION.MK, responsible for configuring the following:
(1) The target platform's ABI type (default: Armeabi) (App_abi)
(2) Toolchains (default: GCC 4.8)
(3) C + + standard library type (default: System) (APP_STL)
(4) Release/debug mode (default: Release)
As we can see, the compilation options involved in this article appear in both Android.mk and application.mk, which we will describe in detail below.
2. App_abi
The ABI full name is: Application Binary interface, the application binary interface, which defines a set of rules that allow compiled binary target code to run without modification in all operating systems and hardware platforms that are compatible with the ABI. (For specific definitions, please refer to Baidu Encyclopedia or Wikipedia)
As can be judged by the above definition, the ABI defines the rules, and the specific implementation is done by the compiler, CPU, and operating system together. Different CPU chips (such as ARM, Intel x86, MIPS) support different ABI architectures, common ABI types include: armeabi,armeabi-v7a,x86,x86_64,mips,mips64,arm64-v8a, etc.
This is why our compiled binaries that run on Windows cannot run on the Mac Os/linux/android platform because the CPU chips and operating systems are different and the same ABI types are supported, so the binary program is not recognized.
And what we call the "cross-compilation" of the core principle is closely related to these, cross-compiling, is the use of cross-compilation tools, on one platform to build a binary executable on another platform, why can do? Because the cross-compilation tool implements the ABI rules defined by another platform. It is also true that we use the Android NDK cross-compilation tool on the Windows/linux platform to compile a library of the Android platform.
This gives the ABI types and differences supported by the latest Android NDK:
650) this.width=650; "src=" Http://s5.51cto.com/wyfs02/M01/79/9D/wKioL1aWQkfj7ZCBAACmr0-XNKI916.png "title=" Abi.png "alt=" Wkiol1awqkfj7zcbaacmr0-xnki916.png "/>
So how do you specify the ABI type? Add a line to the Application.mk file:
App_abi: = armeabi-v7a//Only compile armeabi-v7a version App_abi: = Armeabi armeabi-v7a//Compile armeabi,armeabi-v7a version App_abi: = ALL// Compiling all versions
3. Local_ldlibs
In addition to the Bionic libc Library, the Android NDK also provides a number of other libraries that can be added to the android.mk file by adding dependencies in the following ways:
Local_ldlibs: =-lfoo
The following libraries are linked by default on Android NDK compilation and do not need to be added in Local_ldlibs:
(1) Bionic libc Library
(2) Pthread Library (-lpthread)
(3) Math (-lmath)
(4) C + + Support Library (-lstdc++)
Here I have a list of the libraries supported by different versions of the Android NDK that can be added to "local_ldlibs":
650) this.width=650; "src=" Http://s5.51cto.com/wyfs02/M00/79/9F/wKiom1aWQeijlypkAABItL-vkMM767.png "title=" Lib.png "alt=" Wkiom1awqeijlypkaabitl-vkmm767.png "/>
4. Local_cflags
We can set local_cflags in the Android.mk file to add additional compilation options for compiling the source code, because the NDK actually invokes the GCC command to compile and link, so local_cflags Optional parameter configuration You can refer to the official GCC documentation, linked below:
"GCC 4.8.4 Manual"
"GCC Command Options"
Here are some of the common Cflags compilation options I've summed up:
(1) General compilation options
-O2 compilation optimization options, general selection of O2, taking into account the degree of optimization and target size
-wall Open All warning in the compilation process
-fpic compiled location-independent code, typically used to compile dynamic libraries
-shared Compiling a dynamic library
-FOPENMP Open Multi-core parallel computing,
-idir Configuration header File Search path, if there are multiple-I options, then the search order of the path is left-to-right, that is, the previous path will be selected to search
-nostdinc This option indicates that the search header file under the standard path is not searched, but only the path and current path specified by the-i option.
--sysroot=dir uses dir as the logical root of the header file and library file, for example, under normal circumstances, if the compiler searches the/usr/include header file under/usr/lib, it will use Dir/usr/include and dir/usr/to search the library file. Lib instead of the original corresponding path.
-llibrary find libraries named library for links
-ldir adds the search path to the library file specified by the-l option, that is, the compiler searches the dir path for the library file specified by-L.
-nostdlib This option indicates that you should not use a library file under a standard path when linking
(2) Arm platform-related compilation options
-marm-mthumb Two Select one, specify whether to compile the thumb instruction set or the arm instruction set
-MARCH=NAME specifies a specific ARM architecture, commonly used include:-MARCH=ARMV6,-march=armv7-a
-mfpu=name gives the type of floating-point arithmetic processor for the target platform, commonly used include:-MFPU=NEON,-MFPU=VFPV3-D16
-mfloat-abi=name gives the target platform's floating-point budget ABI, supported parameters include: "soft", "SOFTFP" and "hard"
5. App_stl
Starting with the Android NDK R5 support for STL, just add the APP_STL definition to the Application.mk file:
App_stl: = gnustl_static
By default, the system library supports only a subset of STL features, does not support C + + exceptions, and does not support RTTI, but the NDK integrates a series of other C + + runtime libraries that provide these features, which are as follows:
650) this.width=650; "src=" Http://s2.51cto.com/wyfs02/M01/79/9F/wKiom1aWQvbSNjsAAAAhJnh-sIo760.png "title=" 3.png " alt= "Wkiom1awqvbsnjsaaaahjnh-sio760.png"/>
We can configure which C + + support libraries we choose to use by modifying the App_stl in the Application.mk file:
System, use the default minimal system C + + Runtime library. Gabi++_static, use the gabi++ runtime as a static library. gabi++_shared, use the gabi++ runtime as a shared library. Stlport_static, use the STLport runtime as a static library. stlport_shared, use the STLport runtime as a shared library. Gnustl_static, use the GNU STL as a static library. gnustl_shared, use the GNU STL as a shared library.
6. Summary
about how to set the NDK compilation options here, have any questions, welcome message or letter [email protected] exchange, you can also follow my Sina Weibo @ Lu _ June or the public @Jhuster get the latest articles and information.
This article is from the "jhuster column" blog, be sure to keep this source http://ticktick.blog.51cto.com/823160/1734777
Android Development Practice: How to set the NDK's compilation options