How to Use the android tool chain as an independent Compiler

 

Now we can use the tool chain provided by Android ndk in the form of an independent compiler! This is useful if you already have your own build system.

A typical application scenario is to call a 'configure 'script dependent on the CC environment variable open source library for cross-platform compilation.

 

This document explains how to do that.

1. Select your tool chain:

First, you need to determine whether your independent toolchain targets the target CPU architecture, which is an ARM-based device, a x86-based device, or a MIPS-based device. Each architecture corresponds to a different tool chain Name:

 

* Arm-linux-androideabi-4.6 => for ARM-based Android devices

* X86-4.6 => for x86-based Android devices

* Mipsel-linux-android-4.6 => for MIPS-based Android devices

 

2. Select Your sysroot:

The second thing you should know is that you want to target the android nativeapi. Each level provides different APIs that are described by the DOC/STABLE-APIS.html and correspond to the subfolders of $ ndk/platforms. This allows you to define the path pointing to your 'sysroot'. The GCC path contains the system header file and library. It usually looks like this:

 

Sysroot = $ ndk/platforms/Android-<level>/arch-<arch>/

 

<Level> is the number of API levels, and <arch> is the architecture ("arm", "x86", and "MIPS" can both be used as values ). For example, if you are targeting android2.2 (a.k. A. froyo), you should use:

 

Sysroot = $ ndk/platforms/Android-8/arch-arm

 

Note: x86 and MIPS systems are only supported in Android-9.

3. Call the compiler (stupid way ):

Use the -- sysroot option to call the compiler to indicate the path of the system file for your platform. For example:

Export cc = "$ ndk/toolchains/<Name>/prebuilt/<system>/bin/<prefix> GCC -- sysroot = $ sysroot"

$ CC-O Foo. O-C Foo. c

 

<Name> is the name of a toolchain, <system> is the host system, and <prefix> is the prefix of a specific toolchain. For example, if you use the ndk R5 tool chain on Linux, you will use:

 

Exportcc = "$ ndk/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/ARM-Linux-androideabi-GCC -- sysroot = $ sysroot"

 

As you can see, this is cool, but it does work!

 

Note:

Using the ndk tool chain directly has many restrictions:

You cannot use any c ++ STL (either stlport or GNU libstdc ++ ). You cannot use exceptions or rtti.

 

4. Call the compiler (easy way ):

Ndk allows you to create a "Custom" toolchain and install it to make life easier. For example, the following command:

 

$ Ndk/build/tools/make-standalone-toolchain.sh -- platform = Android-5 -- install-Dir =/tmp/My-Android-toolchain

 

This will create a folder named/tmp/My-Android-toolchain, which contains the test bay of Android-5/arch-armsysroot and the execution file of the tool chain.

 

Note: by default, the ARM-based GCC 4.6 toolchain is selected by the script. Use '-- arch = x86' to specify the gcc of the x86-based, use '-- arch = MIPS' to specify the MIPs-based GCC, or use

'-- Toolchain = <Name>. For example:

 

-- Toolchains = x86-4.4.3 # select x86 GCC 4.4.3 Compiler

-- Toolchain = mipsel-linux-android-4.6 # select mips gcc 4.6 compiler, same as -- arch = MIPS

 

If you want to, you can add -- llvm-version = 3.1 to pass clang/llvm3.1. You can directly use it later. Like:

 

Exportpath =/tmp/My-Android-toolchain/bin: $ path

Exportcc = arm-Linux-androideabi-GCC # or export cc = clang

Exportcxx = arm-Linux-androideabi-G ++ # or export cxx = clang ++

 

Note that without the -- install-Dir option, the make-standalone-toolchain.sh will create a tarball named/tmp/ndk/<toolchain-Name> .tar.bz2. This allows you to easily store and re-release the binary toolkit.

Another important benefit is that this independent tool chain will include a GNU libstdc ++ kibbe that supports exceptions and rtti (when you link to libstdc ++ or libsupc ++ ).

 

Key: toolchain execution files do not depend on or contain characteristic paths on the host. In other words, they can be installed anywhere or moved to another location.

 

Note: you can still use the-sysroot option for the new tool chain, but it is now simpler!

5 Abi compatibility:

The machine code generated using the arm tool chain should be compatible with the official Android 'armeabi 'Abi. We recommend that you use the-mthumb compilation flag to forcibly generate the 16-bit thumb-1 command (the default value is 32-bit ).

 

If you want to target 'armeabi-v7a 'Abi, make sure the following flag is used:

 

Cflags = '-March = armv7-a-mfloat-abi = softfp-mfpu = vfpv3-d16'

 

Note: The First Flag enables the thumb-2 command, and the second enables the H/w fpu command to ensure that the floating point parameter is passed into the core register, which is the key to ABI compatibility. *Not *Use these labels separately!

 

If you want to use the neon command, you need to change the-mfpu compilation flag:

 

Cflags = '-March = armv7-a-mfloat-abi = softfp-mfpu = neon'

 

Note that this forces VFPv3-D32.

Make sure that the following two flags are also provided to the linker:

 

Ldflags = '-March = armv7-a-Wl, -- fix-cortex-a8'

 

Note: the first flag indicates that the linker selects the appropriate libgcc. A, libgcov. A and CRT *. O for the armv7-a. The second sign is used to bypass a CPU bug in some Cortex-A8 devices.

 

If the above does not satisfy you, you 'd better not use an independent tool chain, but stick to the ndk to build the system, which will handle all the details for you.

 

When you are targeting x86 abi or MIPS Abi, you do not need to use any specific compiler flag.

 

6. Warning and restriction: Windows support:

In Windows, the binary file ** does not depend on cygwin. The good news is that they run fast. The bad news is that they do not understand the path form of cygwin, such as/cygdrive/C/Foo/Bar (instead of C:/Foo/bar ).

 

The ndk build system ensures that all paths passed from cygwin to the compiler are automatically converted, and you can cope with the difficult tasks. If you have a custom build system, you need to handle all the problems on your own.

 

Note: There is no plan to support cygwin/msys.

 

Wchar_t support:

 

Before Android 2.3, the Android platform did not really support wchar_t. This indicates:

L if you are targeting Android-9 or a higher platform, the size of wchar_t is 4 bytes, in addition, wide-byte functions are available in most C libraries (except for multibyte codec functions and wsprintf/wsscanf functions ).

L if you are targeting any lower API level, wchar_t has only one byte and cannot be used by any wide byte function.

 

We recommend that all developers remove any dependency on wchar_t and convert it to a better way. Android only supports integrating existing code.

 

Exception, rtti, and STL:

 

The tool chain execution file supports C ++ exceptions and rtti. So when you don't need them, use-fno-exceptions and-fno-rtti to disable them (produce fewer machine codes ).

 

Note: If you want to use these features, you need to explicitly link to libsupc ++. To do this, use-lsupc ++ when linking to a binary file:

 

Arm-Linux-androideabi-G ++...-lsupc ++

 

C ++ STL support:

 

The independent tool chain also comes with a test bay of the GNU libstdc ++ library, which provides an implementation of the C ++ standard template library. To use it, you also need to link to the correct Library:

 

L use-lstdc ++ to link the static library version. This ensures that all the required C ++ STL code is included in your final file. This is recommended.

L use-lgnustl_shared to link the dynamic library version. If you use this method, make sure that libgnustl_shared.so is also copied to your device. This file is located:

$ Toolchain/ARM-Linux-androideabi/lib/for ARM toolchains.

$ Toolchain/i686-linux-android/lib/for x86 ones.

$ Toolchain/mipsel-Linux-android/lib/for MIPS toolchains.

 

The dynamic library version of GNU libstdc ++ is not called libstdc ++. so, this will lead to the minimum C ++ Runtime (/system/lib/libstdc ++. so) conflict. This does not affect static databases.