android-ndk-r8d 使用 獨立 編譯 工具鏈 官方文檔 中英文 對照

USING THE ANDROID TOOLCHAIN AS A STANDALONE COMPILER使用ANDROID作為一個獨立的編譯器工具鏈====================================================== It is now possible to use the toolchains provided with the Android NDK asstandalone compilers. This can be useful if you already have your own buildsystem, and only need to ability to invoke the cross-compiler to add supportto Android for it. 現在可以使用Android NDK 作為獨立編譯器。如果你擁有自己的編譯系統這會很有用 ，僅僅需要有調用支援Android交叉編譯器的能力。   A typical use case if invoking the 'configure' script of an open-sourcelibrary that expects a cross-compiler in the CC environment variable. 一個典型用例，如果調用需要交叉編譯器調用開源庫'configure'指令碼（預設CC環境變數）。  This document explains how to do that:該文檔解釋了如何做: 1/ Selecting your toolchain:選擇你的工具鏈:---------------------------- Before anything else, you need to decide whether your standalone toolchainis going to target ARM-based devices, x86-based, or MIPS-based one.Each architecture corresponds to a different toolchain name.  For example:做任何東西之前,你需要決定你的獨立的工具鏈是基於arm的裝置,基於x86的,或基於mips的哪一個。每個架構對應一個不同的工具鏈的名字。例如:   * 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/ Selecting your sysroot:選擇目錄切換為sysroot:-------------------------- The second thing you need to know is which Android native API level you wantto target. Each one of them provides a different various APIs, which aredocumented under doc/STABLE-APIS.html, and correspond to the sub-directoriesof $NDK/platforms.第二件事你需要知道的是,你需要知道安卓原生API的層級。每一個都提供了一個不同的各種api,這是記錄在doc/STABLE-APIS.html和對應 $NDK/platforms的子目錄中 This allows you to define the path to your 'sysroot', a GCC term for adirectory containing the system headers and libraries of your target.Usually, this will be something like:定義'sysroot'包含目標系統標頭檔和庫。通常，如下：   SYSROOT=$NDK/platforms/android-<level>/arch-<arch>/ Where <level> is the API level number, and <arch> is the architecture("arm", "x86", and "mips" are the supported values). For example, if you'retargeting Android 2.2 (a.k.a. Froyo), you would use:<level>是API 層級 號，<arch>是架構（支援arm，x86，mips）。 例如：如果目標android是2.2，如下：   SYSROOT=$NDK/platforms/android-8/arch-arm IMPORTANT: Note that X86 and MIPS architectures are only supported at android-9 and later.重要：注意X86和MIPS架構只在android-9或更新支援。3/ Invoking the compiler (the hard way):調用編譯器（最困難一步）---------------------------------------- Invoke the compiler using the --sysroot option to indicate where the systemfiles for the platform you're targeting are located. For example, do:使用--sysroot選項來指出系統檔案位置在哪。例如：    export CC="$NDK/toolchains/<name>/prebuilt/<system>/bin/<prefix>gcc --sysroot=$SYSROOT"    $CC -o foo.o -c foo.c Where <name> is the toolchain's name, <system> is the host tag for your system,and <prefix> is a toolchain-specific prefix. For example, if you are on Linuxusing the NDK r5 toolchain, you would use: <name>是工具鏈的名字，<system>是系統主機標誌，<prefix>是工具鏈特定首碼，例如在linux下使用NDK r5工具鏈，如下：    export CC="$NDK/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86/bin/arm-linux-androideabi-gcc --sysroot=$SYSROOT" As you can see, this is rather verbose, but it works!可見，這是很繁瑣，但是有效！IMPORTANT NOTE:重要事項：    Using the NDK toolchain directly has a serious limitation:    You won't be able to use any C++ STL (either STLport or    the GNU libstdc++) with it. Also no exceptions and no RTTI.  直接使用NDK的工具鏈（非獨立版工具鏈）有嚴重的限制：  你不能使用任何C++ STL（STLport或GNU libstdc++）。也沒有異常和運行時類型檢查。 4/ Invoking the compiler (the easy way):調用編譯器（最簡單一步）：---------------------------------------- The NDK allows you to create a "customized" toolchain installation to makelife easier. For example, consider the following command:NDK允許您建立一個“定製”工具鏈安裝。例如,參考下面的命令:  $NDK/build/tools/make-standalone-toolchain.sh --platform=android-5 --install-dir=/tmp/my-android-toolchain This will create a directory named /tmp/my-android-toolchain containing acopy of the android-5/arch-arm sysroot, and of the toolchain binaries.這將建立一個路徑/tmp/my-android-toolchain，包含複製的 android-5/arch-arm sysroot 工具鏈 檔案。 Note that by default, the ARM-based GCC 4.6 toolchain will be selected by the script.Use the '--arch=x86' option to specify the x86 GCC 4.6, or add '--arch=mips' optionto specify the MIPS GCC 4.6, or alternatively'--toolchain=<name>'.  For example:注意預設使用ARM GCC 4.6 工具鏈。使用'--arch=x86'設定x86 GCC 4.6， 或'--arch=mips'設定MIPS GCC 4.6，或者'--toolchain=<name>'來設。例如   --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 If you wish, add '--llvm-version=3.1' to also copy clang/llvm 3.1, oruse --toolchain with '-clang3.1' suffix.  For example:'--llvm-version=3.1'可以複製clang/llvm 3.1或使用--toolchain with '-clang3.1'尾碼，例如：   --toolchain=arm-linux-androideabi-clang3.1  # same as --arch=arm --llvm-version=3.1 You can later use it directly with something like:稍後可用類似如下（匯入環境變數）：    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 without the --install-dir option, make-standalone-toolchain.sh willcreate a tarball in /tmp/ndk/<toolchain-name>.tar.bz2. This allows you toarchive and redistribute the binaries easily.注意未使用--install-dir，make-standalone-toolchain.sh會打包在/tmp/ndk/<toolchain-name>.tar.bz2。使你可以很容易重新發布檔案。 Another important benefit is that this standalone toolchain will contain aworking copy of the GNU libstdc++, with working exceptions and RTTI support(as long as you link against libstdc++ or libsupc++)另一個很便利的地方：獨立工具鏈包含GNU libstdc++（支援異常和RTTI機制），只要你連結到它。 Use --help for more options and details.--help查看更多選項和資訊。 IMPORTANT: The toolchain binaries do not depend or contain host-specific paths,           in other words, they can be installed in any location, or even           moved if you need to.重要:工具鏈的二進位檔案不依賴或包含特定於主機的路徑, 　　換句話說,他們可以安裝在任何位置,甚至如果你需要移動。 NOTE: You can still use the --sysroot option with the new toolchain, but it      is now simply optional!注意:你仍然可以使用--sysroot選項在新的工具鏈,但它現在只是可選的! 5/ About Clang關於Clang--------------------- Clang/clang++ uses the same assembler, linker, headers, libraries and GNUlibstdc++ in the same standalone package.  Clang/clang++ are actually scriptswith "-target" set to the specified architecture at creation.  For example, inARM standalone package, clang is a one-liner:Clang/clang++使用同樣的編譯器，連結器，標頭檔，庫檔案和GNU libstdc++在獨立的包中。Clang/clang++是個指令碼，建立時使用-target指定到特定架構。例如：在ARM獨立包，clang是個單行：    `dirname $0`/clang31 -target armv5te-none-linux-androideabi "$@" clang++ is another:clang++是另一行：    `dirname $0`/clang++31 -target armv5te-none-linux-androideabi "$@" Note that for arm, clang will change target based on the presence ofsubsequent option "-march=armv7-a" and/or "-mthumb".  ie.注意arm，使用-march=armv7-a -mthumb clang將改變-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-androideabi You may override with your own -target if you wish.你可以重寫-target。 Extra efforts have been made to make clang/clang++ easier drop-inreplacements for gcc/g++ in Makefile.  When in doubt, use the followingcommon techniques to check: 做額外的工作替換gcc/g++在Makefile裡。懷疑時，使用下面檢查：   1/ Add option "-v" to dump commands compiler driver issues    -v列印命令編譯器驅動問題  2/ Add option "-###" to dump command line options, including those     implicitly predefined.    -### 列印選項命令列，包含隱式預定義的  3/ Use "-x c /dev/null -dM -E" to dump predefined preprocessor definitions   - x c /dev/null -dM -E 列印預定義的前置處理器定義  4/ Add option "-save-temps" and compare the preprocessed files *.i or *.ii  -save-temps比較預先處理檔案 *.i *.ii See http://clang.llvm.org/, especially the GCC compatibility section.  6/ ABI Compatibility:應用二進位介面相容性：--------------------- The machine code generated by the ARM toolchain should be compatible withthe official Android 'armeabi' ABI (see docs/CPU-ARCH-ABIS.html) by default.ARM工具鏈產生的程式碼應該預設相容官方Android 'armeabi'的應用二進位介面(參照/CPU-ARCH-ABIS.html) It is recommended to use the -mthumb compiler flag to force the generationof 16-bit Thumb-1 instructions (the default being 32-bit ARM ones).推薦使用-mthumb 編譯器標識來強制產生16位Thumb-1指令（預設是32位ARM的指令） If you want to target the 'armeabi-v7a' ABI, you will need ensure that thefollowing flags are being used:如果你的目標是'armeabi-v7a'的應用二進位介面，你需要確保使用如下標誌：   CFLAGS='-march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16' Note: The first flag enables Thumb-2 instructions, and the second one      enables H/W FPU instructions while ensuring that floating-point      parameters are passed in core registers, which is critical for      ABI compatibility. Do *not* use these flags separately!注意：第一個標誌啟用Thumb-2指令，第二個啟用H/W浮點處理器指令功能，確保用核心寄存器傳遞浮點參數，它對於ABI相容性來說是關鍵。不要分開使用這些開關！ If you want to use Neon instructions, you will need to change the -mfpucompiler flag:如果你想使用Neon指令（ARM的單指令多資料技術），你需要再增多一個編譯器開關：   CFLAGS='-march=armv7-a -mfloat-abi=softfp -mfpu=neon' Note that this forces the use of VFPv3-D32, as per the ARM specification.注意它強制使用VFPv3-D32（註：VFPv3是vector floating point v3的縮寫，即向量浮點第三版，D32應該是指32個雙精確度浮點寄存器），根據ARM規範。 Also, make sure the following two flags are provided to linker:還有，確保下連結器使用以下兩個標誌。   LDFLAGS='-march=armv7-a -Wl,--fix-cortex-a8' Note: The first flag instructs linker to pick libgcc.a, libgcov.a and      crt*.o tailored for armv7-a.  The 2nd flag is *required* to route      around a CPU bug in some Cortex-A8 implementations:注意：第一個標誌連接器選擇特別為armv7-a設計的libgcc.a libgcov.a和crt*.o。      第二個標誌是繞過一些Cortex-A8 CPU bug的實現所需。 If none of the above makes sense to you, it's probably better not to usethe standalone toolchain, and stick to the NDK build system instead, whichwill handle all the details for you.如果上面的東西對你不起作用，最好不要使用獨立工具鏈，還是堅持使用NDK構建系統，它將為你處理所有細節。 You don't have to use any specific compiler flag when targeting the x86 ABIor the MIPS ABI.當目標是x86 ABI或MIPS ABI時，你不需要使用人任何特殊編譯器標誌。 7/ Warnings and Limitations:警告和限制：-------------------------- 7.1/ Windows support:Windows支援：- - - - - - - - - - - The Windows binaries do *not* depend on Cygwin. The good news is that theyare thus faster, the bad news is that they do not understand the Cygwinpath specification like /cygdrive/c/foo/bar (instead of C:/foo/bar).Windows二進位檔案不依賴於Cygwin。好訊息是它們會跑得更快，而壞訊息是它們不理解Cygwin的目錄格式，像/cygdrive/c/foo/bar（但可以理解C:/foo/bar） The NDK build system ensures that all paths passed to the compiler from Cygwinare automatically translated, and deals with other horrors for you. If you havea custom build system, you may need to deal with the problem yourself.NDK構建系統確保從Cygwin中傳遞的所有路徑被自動翻譯，為你處理其它威脅。如果你擁有一個定製構建系統，你可能需要自己處理問題。 NOTE: There is no plan to support Cygwin / MSys at the moment, but      contributions are welcome. Contact the android-ndk forum for details.注意：現在沒計劃支援Cygwin / MSys，但歡迎貢獻。詳細請聯絡android-ndk論壇 7.2/ wchar_t support:wchar_t支援：- - - - - - - - - - - As documented, the Android platform did not really support wchar_t untilAndroid 2.3. What this means in practical terms is that:正如文檔所寫的，Android平台在Android 2.3之前沒有真正支援wchar_t。用實際的術語說，這意味著：    - If you target platform android-9 or higher, the size of wchar_t is    4 bytes, and most wide-char functions are available in the C library    (with the exception of multi-byte encoding/decoding functions and     wsprintf/wsscanf).  - 如果你的目標平台是android-9或更高，wchar_t的大小是4位元組，則在C庫中大多數    寬字元函數可用（例外的是多位元組的編碼解碼函數和wsprintf/wsscanf）   - If you target any prior API level, the size of wchar_t will be 1 byte    and none of the wide-char functions will work anyway.  - 如果你的目標是較早的API層級，wchar_t的大小將是1位元組，任何寬字元函數都不可工作。 We recommend any developer to get rid of any dependencies on the wchar_t typeand switch to better representations. The support provided in Android is onlythere to help you migrate existing code.我們建議所有開發人員避免對wchar_t類型的依賴，而是轉向更好的表示。在Android中提供的支援只出現在協助你遷移現存代碼的地方。 7.3/ Exceptions, RTTI and STL:異常、運行時類型識別和STL（標準模板庫）：- - - - - - - - - - - - - - - The toolchain binaries *do* support C++ exceptions and RTTI by default.They are enabled by default, so use -fno-exceptions and -fno-rtti if youwant to disable them when building sources with them (e.g. to generatesmaller machine code).工具鏈二進位檔案預設支援C++異常和RTTI（運行時類型識別）。它們預設是開啟的，所以如果你想在構建使用它們的代碼時關閉它們，請使用-fno-exceptions和-fno-rtti（例如，為了產生更小的機器代碼）。 NOTE: You will need to explicitly link with libsupc++ if you use these      features. To do this, use -lsupc++ when linking binaries, as in:注意：你將需要顯式地用libsupc++連結，如果你使用這些特性。為了做到這點，當連結二進位檔案時使用-lsupc++，像這樣：（註：這裡要小心，是libsupc++不是libstdc++！）     arm-linux-androideabi-g++ .... -lsupc++  7.4/ C++ STL support: C++標準模板庫支援：- - - - - - - - - - - The standalone toolchain also comes with a copy of the GNU libstdc++library, which provides an implementation of the C++ Standard TemplateLibrary. To use it, you however need to link with the proper library:工具鏈還帶有一個可用的GNU libstdc++實現，它提供一個工作的C++標準模板庫實現。你將需要顯式地用-lstdc++連結以使用它。   * Use -lstdc++ to link against the _static_ library version. This ensures    that all required C++ STL code is included into your final binary. This    is ideal if you are only generating a single shared library or executable.    使用-lstdc++ 來連結靜態庫版本。這確保了所需C++STL程式碼封裝含進你的最終二進位檔案。    這是一個產生單獨共用庫或執行檔案的辦法。    This is the recommended way to do it.    這是推薦的方式。   * Use -lgnustl_shared to link against the _shared_ library version. This    is required if you have several related shared libraries or executables    that need to run in the same address space at runtime (some global variables    need to be defined uniquely, which is not possible if you link the static    libstdc++ against each one of your executables).    使用-lgnustl_shared來連結靜態庫版本。如果你有幾個相關的需要運行時在同樣的地址空間    的共用庫或執行檔案，這是必須的。   （一些全域變數需要唯一的定義，不適用於每一個可執行檔連結靜態libstdc++）        If you use this option, you need to ensure that libgnustl_shared.so is    also copied to your device for your code to load properly. The file is    at:    如果你使用此選項，你需要確保libgnustl_shared.so拷貝到你裝置上以便載入。檔案在：       $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: The GNU libstdc++ is licensed under the GPLv3 with a               linking exception. See the following URL for details: 重要：GNU libstdc++ 授權在GPLv3，有一個例外，查看如下URL來詳細描述：          http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt01ch01s02.html     If you cannot comply with its requirements, i.e. you cannot redistribute    the shared library, do not use it in your project. www.2cto.com    如果你不能幹遵守它的要求，你不能發布這個共用庫，不能使用在你的工程中。 The reason the shared version of GNU libstdc++ is not called libstdc++.so isbecause this would conflict at runtime with the system's own minimal C++runtime, which is /system/lib/libstdc++.so. This enforces a new name for theGNU ELF library. This is not a problem for the static library.共用版GNU libstdc++不被叫做libstdc++.so的原因是這將會在運行時和最小C++執行階段程式庫（/system/lib/libstdc++.so）衝突。這強制了一個GNU ELF庫的新名字。對於靜態庫這不是個問題。