• Home
  • Raw
  • Download

Lines Matching refs:to

4 It is now possible to use the toolchains provided with the Android NDK as
6 system, and only need to ability to invoke the cross-compiler to add support
7 to Android for it.
13 This document explains how to do that:
18 Before anything else, you need to decide whether your standalone toolchain
19 is going to target ARM-based devices, x86-based, or MIPS-based one.
20 Each architecture corresponds to a different toolchain name. For example:
29 The second thing you need to know is which Android native API level you want
30 to target. Each one of them provides a different various APIs, which are
31 documented under doc/STABLE-APIS.html, and correspond to the sub-directories
34 This allows you to define the path to your 'sysroot', a GCC term for a
51 Invoke the compiler using the --sysroot option to indicate where the system
68 You won't be able to use any C++ STL (STLport, libc++,
71 > For clang, you need to add correct "-target" for given architecture, and add
72 "-gcc-toolchain" to path of GNU-based toolchain for "as" and "ld", eg.
82 The NDK allows you to create a "customized" toolchain installation to make
91 Use the '--arch=x86' option to specify the x86 GCC 4.6, or add '--arch=mips' option
92 to specify the MIPS GCC 4.6, or alternatively
99 If you wish, add '--llvm-version=3.3' to also copy clang/llvm 3.3, or
105 MacOSX to make 64-bit host toolchain instead of the 32-bit one (default).
108 You may specify --stl=stlport to copy libstlport instead of libgnustl. Note that
109 to link against the shared library, you will have to explicitely use -lstlport_shared
110 in this case, just like you need to use -lgnustl_shared for the GNU libstdc++ case.
113 Likewise you may specify --stl=libc++ to copy LLVM libc++ headers and libraries. Note that
114 to link against the shared library, you will have to explicitely use -lc++_shared.
123 create a tarball in /tmp/ndk/<toolchain-name>.tar.bz2. This allows you to
133 moved if you need to.
142 It is possible to also install Clang binaries in the standalone
151 Note that Clang binaries are copied in addition to the GCC ones, because
158 you should be able to use them in your own builds by setting CC and CXX
159 environment variables to point to them.
183 Extra efforts have been made to make clang/clang++ easier drop-in
185 common techniques to check:
187 1. Add option "`-v`" to dump commands compiler driver issues
188 2. Add option "`-###`" to dump command line options, including those
190 3. Use "`-x c` `/dev/null` `-dM` `-E`" to dump predefined preprocessor definitions
202 It is recommended to use the -mthumb compiler flag to force the generation
205 If you want to target the 'armeabi-v7a' ABI, you will need ensure that the
216 If you want to use Neon instructions, you will need to change the -mfpu
223 Also, make sure the following two flags are provided to linker:
227 Note: The first flag instructs linker to pick libgcc.a, libgcov.a and
228 crt*.o tailored for armv7-a. The 2nd flag is *required* to route
232 has __attribute__((pcs("aapcs"))) for ARM. It's possible to compile
237 If you want to use Neon intrinsics on x86 they can be translated to the native
240 By default x86 ABI supports SIMD up to SSE3 and the header covers ~83% NEON
241 functions (1551 of total 1872). It is recommended to use the -mssse3 compiler
242 flag which extends SIMD up to SSSE3 and in this case the header will cover
249 If none of the above makes sense to you, it's probably better not to use
250 the standalone toolchain, and stick to the NDK build system instead, which
253 You don't have to use any specific compiler flag when targeting the MIPS ABI.
264 The NDK build system ensures that all paths passed to the compiler from Cygwin
266 a custom build system, you may need to deal with the problem yourself.
268 NOTE: There is no plan to support Cygwin / MSys at the moment, but
285 We recommend any developer to get rid of any dependencies on the wchar_t type
286 and switch to better representations. The support provided in Android is only
287 there to help you migrate existing code.
294 want to disable them when building sources with them (e.g. to generate
297 NOTE: If you use the GNU libstdc++, you will need to explicitly link with
311 implementation, you however need to link your project with the proper
314 * Use -lstdc++ to link against the _static_ library version of any
319 This is the recommended way to do it.
321 * Use -lgnustl_shared to link against the _shared_ library version of
322 GNU libstdc++. If you use this option, you need to ensure that
323 `libgnustl_shared.so` is also copied to your device for your code to
338 * Use -lstlport_shared to link against the _shared_ library version of
339 STLport. If you use this option, you need to ensure that
340 `libstlport_shared.so` is also copied to your device for your code
341 to load properly. They are found at the same locations than those