Android-ndk-r8d using independent compilation toolchain official documentation

Use ANDROID as an independent compiler tool chain ================================ =================================== this document explains how to do: 1/select your toolchain: ---------------------------- before doing anything, you need to decide whether your independent toolchain is based on arm devices, based on x86, or the mips-based one. Each architecture corresponds to a different tool chain name. Example: * arm-linux-androideabi-4.6 => targeting ARM-based Android devices * x86-4.6 => targeting x86-based Android devices * mipsel-linux-android-4.6 => targeting MIPS-based Android devices 2/select the directory to switch to sysroot: ------------------------ The second thing you need to know is that you need to know the level of Android native API. Each provides a different set of APIS, which are documented in the doc/STABLE-APIS.html and corresponding to the $ NDK/platforms subdirectory that defines 'sysroot' to contain the destination system header file and library. Generally, SYSROOT = $ NDK/platforms/android-<level>/arch-<arch>/<level> indicates the API level number, and <arch> indicates the architecture (supports arm, x86, mips ). For example, if the target android is 2.2, as follows: SYSROOT = $ NDK/platforms/android-8/arch-arm important: note that the X86 and MIPS architectures are only supported in android-9 or later versions. 3/call the compiler (the most difficult step) -------------------------------------- use the -- sysroot option to indicate where the system file is located. 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 the toolchain, <system> is the identifier of the system host, and <prefix> is the specific prefix of the toolchain. For example, use the NDK r5 toolchain in linux, as shown below: export CC = "$ NDK/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-gcc -- sysroot = $ SYSROOT" visible, this is tedious but effective! Important: the direct use of NDK tool chain (non-independent version tool chain) has severe restrictions: you cannot use any C ++ STL (STLport or GNU libstdc ++ ). No exception or runtime type check. 4/call the compiler (the simplest step): ---------------------------------------- NDK allows you to create a "Custom" toolchain for installation. For example, refer to the following command: $ NDK/build/tools/make-standalone-toolchain.sh -- platform = android-5 -- install-dir =/tmp/my-android-toolchain this will resume a path/tmp/my-android-toolchain, contains the copied android-5/arch-arm sysroot tool chain file. Note that arm gcc 4.6 is used by default. Use '-- arch = x86' to set x86 GCC 4.6, '-- arch = mips' to set mips gcc 4.6, or '-- toolchain = <name>. For example -- toolchain = x86-4.4.3 # select x86 GCC 4.4.3 compiler -- toolchain = arm-linux-androideabi-4.7 # select arm gcc 4.7 compiler -- toolchain = mipsel-linux-android-4.6 # select mips gcc 4.6 compiler, same as -- arch = mips '-- llvm-version = 3.1' can be used to copy clang/llvm 3.1 or use the suffix -- toolchain with '-clang3.1', for example: -- toolchain = arm-linux-androideabi-clang3.1 # same as -- arch = arm -- llvm-version = 3.1 later available similar to the following (import environment variable): export PAT H =/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 use -- install-dir, the make-standalone-toolchain.sh is packaged in/tmp/ndk/<toolchain-name> .tar.bz2. So that you can easily re-release files. Another convenient place: the independent tool chain includes GNU libstdc ++ (supports exception and RTTI mechanisms), as long as you link to it. -- Help to view more options and information. Important: the tool chain binary files do not depend on or contain host-specific paths. In other words, they can be installed anywhere, even if you need to move. Note: you can still use the -- sysroot option in the new tool chain, but it is only optional now! 5/Clang --------------------- Clang/clang ++ uses the same compiler, linker, header file, library file and GNU libstdc ++ in a separate package. Clang/clang ++ is a script, which is specified to a specific architecture using-target during creation. For example, in an ARM stand-alone package, clang is a single row: 'dirname $ 0'/clang31-target armv5te-none-linux-androideabi "$ @" clang ++ is another row: 'dirname $ 0'/clang ++ 31-target armv5te-none-linux-androideabi "$ @" note arm, use-march = armv7-a-mthumb clang will change-target 1/With "-march = armv7-a",-target becomes armv7-none-linux-androideabi 2/With "-mthumb ", -target becomes thumb-none-linux-androideabi 3/With both,-target becomes thumbv7-none-linux-and You can override-target in roideabi. Do additional work to replace gcc/g ++ in Makefile. In case of suspicion, use the following check: 1/Add option "-v" to dump commands compiler driver issues print command compiler driver problem 2/Add option "-###" to dump command line options, including those implicitly predefined. print option command line, contains implicitly predefined 3/Use "-x c/dev/null-dM-E" to dump predefined preprocessor definitions print predefined preprocessor definitions 4/Add option "-save -temps "and compare the preprocessed files *. I or *. ii compare preprocessing files See http://clang.llvm.org/, especially t He GCC compatibility section. 6/Application binary interface compatibility: --------------------- ARM tool chain generated code should be compatible with the official Android 'armeabi 'application binary interface by default (reference/CPU-ARCH-ABIS.html) we recommend that you use the-mthumb compiler identifier to forcibly generate the 16-bit Thumb-1 command (32-bit ARM command by default). If your target is an application binary interface of 'armeabi-v7a, you need to make sure to use the following flag: CFLAGS = '-march = armv7-a-mfloat-abi = softfp-mfpu = vfpv3-d16' Note: the first flag enables the Thumb-2 command, the second option is to enable the H/W floating point processor command to ensure that floating point parameters are transmitted using core registers, which is critical for ABI compatibility. Do not use these switches separately! If you want to use the Neon command (ARM's single-instruction multi-data technology), you need to add another compiler switch: CFLAGS = '-march = armv7-a-mfloat-abi = softfp-mfpu = neon 'note that this forces the use of VFPv3-D32, as per the ARM specification. note that it enforces the use of VFPv3-D32 (Note: VFPv3 is the abbreviation of vector floating point v3, the third edition of vector floating point, and D32 should refer to 32 Double Precision floating point registers), according to ARM specifications. Also, make sure the following two flags are provided to linker: Also, make sure that the lower linker uses the following two flags. LDFLAGS = '-march = armv7-a-Wl, -- fix-cortex-a8' Note: The first sign connector selects libgcc. a libgcov. a and crt *. o specifically designed for the armv7-a. The second sign is needed to bypass some Cortex-A8 CPU bugs. If the above things do not work for you, it is best not to use an independent tool chain, or stick to using NDK to build a system, it will process all the details for you. When the target is x86 ABI or mips abi, you do not need to use any special compiler flag. 7/warning and restrictions: ------------------------ 7.1/Windows support:--Windows binary files do not depend on Cygwin. The good news is that they will run faster, and the bad news is that they do not understand the Cygwin directory format, such as/cygdrive/c/foo/bar (but can understand C:/foo/bar) the NDK build system ensures that all paths passed from Cygwin are automatically translated to handle other threats for you. If you have a custom build system, you may need to handle the problem on your own. Note: Cygwin/MSys is not supported yet, but you are welcome to contribute. For details, please contact the android-ndk Forum 7.2/wchar_t support:---as shown in the document, the Android platform did not actually support wchar_t before Android 2.3. In actual terms, this means:-If your target platform is android-9 or higher, the size of wchar_t is 4 bytes, most of the wide character functions are available in the C library (except the multi-byte encoding and decoding functions and wsprintf/wsscanf)-If your target is an earlier API level, the size of wchar_t will be 1 byte, and no wide character function can work. We recommend that all developers avoid dependency on the wchar_t type, but turn to a better representation. The support provided in Android only appears where you can migrate existing code. 7.3/exception, runtime type recognition and STL (Standard Template Library ): --tool chain binary files support C ++ exceptions and RTTI by default (runtime type identification ). They are open by default, so if you want to disable them when building code that uses them, use-fno-exceptions and-fno-rtti (for example, to generate smaller machine code ). Note: you will need to explicitly use libsupc ++ links if you use these features. To do this, use-lsupc ++ when linking a binary file, as shown in the following figure: (Note: Please be careful that libsupc ++ is not libstdc ++ !) Arm-linux-androideabi-g ++ .... -supported by lsupc ++ 7.4/C ++ STL:---tool chain also comes with an available GNU libstdc ++ implementation, it provides a standard template library for C ++. You will need to explicitly use the-lstdc ++ link to use it. * Use-lstdc ++ to link the static library version. This ensures that the required C ++ STL code is included in your final binary file. This is a way to generate a separate shared library or execution file. This is the recommended way to do it. This is the recommended method. * Use-lgnustl_shared to link the static library version. If you have several related libraries or execution files that need to be shared in the same address space during runtime, this is required. (Some global variables need a unique definition and are not applicable to the static libstdc ++ of every Executable File Link.) If you use this option, make sure that libgnustl_shared.so is copied to your device for loading. The file is in $ TOOLCHAIN/arm-linux-androideabi/lib/for ARM toolchains. $ TOOLCHAIN/i686-linux-android/lib/for x86 ones. $ TOOLCHAIN/mipsel-linux-android/lib/for MIPS toolchains. important: GNU libstdc ++ is authorized in GPLv3, with an exception, view the following URL to describe in detail: http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt01ch01s02.html if you cannot do what it requires, you cannot publish this shared library, it cannot be used in your project. The shared version of GNU libstdc ++ is not called libstdc ++. the reason for so is that this will cause the Library (/system/lib/libstdc ++) during runtime and the minimum C ++ runtime. so) conflict. This forces a new name for the gnu elf library. Static databases are not a problem.