NDK Compilation-Standalone tool chain

The content of the article is from the Android Developer's official website, in order to prevent the re-entry, record a bit. Website: https://developer.android.com/ndk/guides/standalone_toolchain.html

Standalone tool chain content Select your Toolchain Select your sysroot call compiler to use Clang ABI compatibility warnings and restrictions

You can use the toolchain included with the Android NDK independently, or use it as a plug-in in conjunction with an existing IDE. This flexibility is useful if you already have your own build system, and you only need to call the cross-compiler feature to add support for your build system to Android.

A typical use case is to invoke a configure script in the CC environment variable that requires a cross-compiler open Source Library.

Note : This page assumes you are familiar with compiling, linking, and low-level architectures. In addition, the techniques presented on this page are not required for most use cases. In most cases, we recommend that you abandon the use of an independent toolchain, but instead stick to the NDK build system. Choose your tool chain

First, you need to decide which processing architecture your stand-alone toolchain will target. Each schema corresponds to a different tool chain name, as shown in table 1.

table 1. App_abi settings for different instruction sets.

Architecture	Tool chain name
Based on ARM	Arm-linux-androideabi-<gcc-version>
Based on x86	X86-<gcc-version>
Based on MIPS	Mipsel-linux-android-<gcc-version>
Based on ARM64	Aarch64-linux-android-<gcc-version>
Based on x86-64	X86_64-<gcc-version>
Based on MIPS64	Mips64el-linux-android--<gcc-version>

Choose your Sysroot

The next thing you need to do is define your Sysroot (Sysroot is a directory that contains the system headers and libraries for your target). To define Sysroot, you must know the target Android API level natively supported, and the available native APIs will vary depending on the Android API level.

Native APIs for the corresponding Android API level are located under the $NDK/platforms/, and each API level directory contains subdirectories for a variety of CPUs and schemas. The following example shows how to define sysroot for a build that targets the ARM architecture for Android 5.0 (API level 21):

sysroot= $NDK/platforms/android-21/arch-arm

For more information on the Android API levels and the corresponding native APIs supported, see the Android NDK native API. invoking the compiler

There are two ways to invoke the compiler. One method is simple, and most of the transactions are done by the build system. The other approach is more complex, but provides more flexibility. Simple Method

The simplest way to build is to invoke the appropriate compiler directly from the command line, using the--sysroot option to indicate the system file location of your target platform. For example:

Export cc= "$NDK/toolchains/arm-linux-androideabi-4.8/prebuilt/\
linux-x86/bin/arm-linux-androideabi-gcc-4.8 --sysroot= $SYSROOT "
$CC-o foo.o-c foo.c

Although this approach is simple, it lacks flexibility: it does not allow you to use any C + + STL (STLport, libc++, or GNU libstdc++). It also does not support exceptions or RTTI.

For Clang, you need to perform two additional steps: Add the appropriate-target for the target schema, as shown in table 2.

table 2. The value of the schema and corresponding-target.

Architecture	value
Armeabi	-target Armv5te-none-linux-androideabi
armeabi-v7a	-target Armv7-none-linux-androideabi
arm64-v8a	-target aarch64-none-linux-android
x86	-target i686-none-linux-android
x86_64	-target x86_64-none-linux-android
Mips	-target mipsel-none-linux-android

Add assembler and linker support by adding the-gcc-toolchain option, as shown in the following example:

-gcc-toolchain $NDK/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64

Finally, a command that compiles with Clang might look like this:

Export cc= "$NDK/toolchains/arm-linux-androideabi-4.8/prebuilt/\
linux-x86/bin/arm-linux-androideabi-gcc-4.8 --sysroot= $SYSROOT "-target \
armv7-none-linux-androideabi \
-gcc-toolchain $NDK/toolchains/ Arm-linux-androideabi-4.8/prebuilt/linux-x86_64 "
$CC-o foo.o-c foo.c

Advanced Methods

The NDK provides make-standalone-toolchain.sh shell scripts to allow you to perform customized toolchain installations from the command line. This method gives you more flexibility than the program described in the simple method.

The script is located in the $NDK/build/tools/directory, where $NDK is the installation root of the NDK. An example of using this script is shown below:

$NDK/build/tools/make-standalone-toolchain.sh \
--arch=arm--platform=android-21--install-dir=/tmp/ My-android-toolchain

This command creates a directory named/tmp/my-android-toolchain/that contains a copy of the Android-21/arch-arm sysroot and a copy of the tool chain binaries for the 32-bit ARM architecture.

Note that toolchain binaries do not depend on or contain host-specific paths, in other words, you can install them anywhere, or even move them if needed.

By default, the build system uses the 32-bit, ARM-based GCC 4.8 toolchain. However, you can specify a different value by specifying--arch=<toolchain> as an option. Table 3 shows the values that will be used for other toolchain:

table 3. Tool chain and corresponding values, using--arch.

tool Chain	value
Mips64 compiler	--arch=mips64
MIPS GCC 4.8 Compiler	--arch=mips
x86 GCC 4.8 Compiler	--arch=x86
x86_64 GCC 4.8 Compiler	--arch=x86_64
MIPS GCC 4.8 Compiler	--arch=mips

Alternatively, you can use the--toolchain=<toolchain> option. Table 4 shows the values you can specify for <toolchain>:

table 4. Tool chain and corresponding values, using--toolchain.

tool Chain	value
Arm	--toolchain=arm-linux-androideabi-4.8--toolchain=arm-linux-androideabi-4.9--toolchain= arm-linux-android-clang3.5--toolchain=arm-linux-android-clang3.6
x86	--toolchain=x86-linux-android-4.8--toolchain=x86-linux-android-4.9--toolchain= x86-linux-android-clang3.5--toolchain=x86-linux-android-clang3.6
Mips	--toolchain=mips-linux-android-4.8--toolchain=mips-linux-android-4.9--toolchain= mips-linux-android-clang3.5--toolchain=mips-linux-android-clang3.6
Arm64	--toolchain=aarch64-linux-android-4.9--toolchain=aarch64-linux-android-clang3.5--toolchain= aarch64-linux-android-clang3.6
x86_64	--toolchain=x86_64-linux-android-4.9--toolchain=x86_64-linux-android-clang3.5--toolchain=x86_64- linux-android-clang3.6
Mips64	--toolchain=mips64el-linux-android-4.9--toolchain=mips64el-linux-android-clang3.5--toolchain= mips64el-linux-android-clang3.6

Note: table 4 is not an exhaustive list. Other combinations may also be valid, but unverified.

You can also copy CLANG/LLVM 3.6 using one of the following two methods: You can attach-clang3.6 to the--toolchain option so that the--toolchain option looks like the following example:

--toolchain=arm-linux-androideabi-clang3.6

You can also add-llvm-version=3.6 as a separate option on the command line.

Note: You do not need to specify a specific version, you can also use <VERSION>, which uses the highest available Clang version by default.

By default, the build system is built for the 32-bit host toolchain. You can specify a 64-bit host chain to replace it. Table 5 shows the values that will be used with-system for different platforms.

table 5. The host toolchain and corresponding values, using-system.

Host tool Chain	value
64-bit Linux	-system=linux-x86_64
64-bit MACOSX	-system=darwin-x86_64
64-bit Windows	-system=windows-x86_64

For more information about specifying a 64 or 32-bit instruction host toolchain, see 64-bit and 32-bit toolchain.

Instead of using the default LIBGNUSTL, you can specify--stl=stlport to replicate Libstlport. If you do this and want to link a shared library, you must use-lstlport_shared explicitly. This requirement is similar to the use of-lgnustl_shared that must be used for GNU libstdc++.

Similarly, you can specify--stl=libc++ to replicate LLVM libc++ headers and libraries. If you want to link a shared library, you must use-lc++_shared in an explicit manner.

You can make these settings directly, as shown in the following example:

Export Path=/tmp/my-android-toolchain/bin: $PATH
export CC=ARM-LINUX-ANDROIDEABI-GCC   # or Export Cc=clang
export cxx=arm-linux-androideabi-g++  # or Export cxx=clang++

Note that if you omit the-install-dir option, the make-standalone-toolchain.sh shell script creates a tmp/ndk/<toolchain-name>.tar.bz2 in the Tarball This tarball makes it easy to archive and redistribute binaries.

This standalone toolchain also provides an additional benefit: it contains a copy of the work of a C + + STL library and in-work exceptions and RTTI support.

For more options and more information, please use--HELP. using Clang

You can use the--llvm-version=<version> option to install the Clang binaries in a stand-alone installation. <version> is a Llvm/clang version number, such as 3.5 or 3.6. For example:

build/tools/make-standalone-toolchain.sh \
--install-dir=/tmp/mydir \
--toolchain= arm-linux-androideabi-4.8 \
--llvm-version=3.6

Note that the Clang binaries are copied with the GCC binaries because they depend on the same assembler, linker, headers, libraries, and C + + STL implementations.

This operation will also install two scripts named Clang and clang++ under <install-dir>/bin/@. These scripts invoke the real clang binaries using the default target schema flags. In other words, they can run without any modification, and you can use them in your own build simply by setting the CC CXX environment variables that point to them. Call Clang

In an ARM stand-alone installation built using llvm-version=3.6, calling Clang on a Unix system is a single-line form. For example:

' DirName '/clang36-target armv5te-none-linux-androideabi "$@"

clang++ calls clang++31 in the same way. Clang ARM as the target

When building against ARM, Clang changes the target based on whether the-march=armv7-a and/or-MTHUMB options are present:

table 5. The-march value that can be specified and the target it generates.

-march Value	the generated target
-march=armv7-a	Armv7-none-linux-androideabi
-mthumb	Thumb-none-linux-androideabi
-march=armv7-a and-mthumb	Thumbv7-none-linux-androideabi

If you wish, you can also replace it with your own-target.

The-gcc-toolchain option is not required because in a standalone package, Clang looks for AS and LD in a predefined relative position.

Clang and clang++ should be able to easily replace GCC and g++ in makefile. If in doubt, add the following options to verify that they are running correctly. -V, which is used to dump command-### related to compiler driver issues, for dumping command-line options, including implicitly-predefined options. -X C </dev/null-dm-e for staging pre-defined preprocessor definition-save-temps for comparing *.i or *.II preprocessing files.

For more information about Clang, see http://clang.llvm.org/, especially the GCC compatibility section. ABI Compatibility

By default, the machine code generated by the ARM Toolchain should be compatible with the official Android Armeabi ABI.

We recommend using the-MTHUMB compiler flag to force the generation of a 16-bit Thumb-1 instruction (by default, the 32-bit ARM directive).

If you want to target the armeabi-v7a ABI, you must set the following flags:

cflags=-march=armv7-a-mfloat-abi=softfp-mfpu=vfpv3-d16

The first flag enables the THUMB-2 directive. The second flag enables the hardware FPU directive, while ensuring that the system passes floating-point parameters in the core register, which is critical for ABI compatibility.

Note: do not use these flags alone in the previous NDK version of r9b. You must also set all flags or none at the same time. Failure to do so may result in unpredictable behavior and crashes.

To use the NEON directive, you must change the-MFPU compiler flag:

cflags=-march=armv7-a-mfloat-abi=softfp-mfpu=neon

Please note that this setting enforces the use of vfpv3-d32, as per the ARM specification.

Also, make sure that you provide the following two flags to the linker:

ldflags=-march=armv7-a-wl,--fix-cortex-a8

The first flag instructs the linker to select LIBGCC.A, LIBGCOV.A, and crt*.o that are customized for armv7-a. In some CORTEX-A8 implementations, a second flag is required as a workaround for CPU errors.

Starting with NDK version r9b, all Android native APIs that get or return double or floating point values have a attribute ((PCs ("aAPCs")) for ARM. This allows you to compile the user code in-mhard-float (which represents-mfloat-abi=hard) and still associate with the Android native API that complies with the SOFTFP ABI. For more information about this, see the comments in $NDK/tests/device/hard-float/jni/android.mk.

If you are using NEON intrinsics on x86, the build system can convert them to native arm_neon.h SSE inline functions using a special C + + language header that has the same name x86 as the standard ARM NEON inline function header.

By default, the x86 ABI supports SIMD SSSE3 maximum, and the header covers about 93% of the NEON function (1869 (total 2009)).

If you target the MIPS ABI, you do not have to use any specific compiler flags.

For more information about ABI support, see x86 support. Warnings and Restrictions Windows Support

Windows binaries are not dependent on Cygwin. This independence allows them to run faster. However, the price is that they do not understand the Cygwin path specification, such as Cygdrive/c/foo/bar, but can understand C:/foo/bar.

The NDK build system ensures that all paths passed from Cygwin to the compiler are automatically converted, while managing other complexities. If you have a custom build system, you may need to address these complexities yourself.

For information on contributing support for Cygwin/msys, please visit the ANDROID-NDK forum. wchar_t Support

The Android platform did not really support wchar_t before Android 2.3 (API level 9). This situation produces multiple results: If your target platform is Android 2.3 or later, the size of the wchar_t is 4 bytes, and most Wide-char functions are available in the C library (except for multibyte encoding/decoding functions and WSPRINTF/WSSCANF). If you target any of the lower API levels, the size of the wchar_t is 1 bytes, and any Wide-char function cannot run.

We recommend that you do not rely on the wchar_t type and use a better representation instead. This support is provided in Android to help you migrate existing code. exceptions, RTTI, and STL