Our android applications use multiple shared and static libraries that were pointing to the clang 3.5 tool chain via the Application.mk NDK_TOOLCHAIN_VERSION=clang3.5. We use command line ndk-build. A fairly significant update to the android ndk tor11 was just released, release notes indicate that everything now uses clang and that latest clang is 3.8. After upgrading to r11 the clang tool chain doesn't appear to be anywhere in the updated ndk. My question simply is where do find/install/update the missing toolchain(s). All I see in the in the /ndk-bundle/toolchains/ is ... android??/x86 .. 4.9 which is not clang.
Any help or insight would be greatly appreciated.
Try using clang instead of clang3.5.
Related
I'm migrating from ndk-build to CMake (it better integrates with Android Studio, and would enable us to have a single CMakeLists.txt for all platforms).
Unfortunately, our projects use some features of Android.mk that I'm not being able to replicate with CMake. More specifically:
TARGET_ARCH: we use this to include different pre-compiled binaries. How can I find the target arch with CMake?
LOCAL_ARM_MODE: is this even available in CMake?
EDIT:
When using Gradle, CMAKE_ANDROID_ARCH_ABI is not set! Use CMAKE_ANDROID_ARCH or ANDROID_ABI.
ORIGINAL:
After a bit more of Google, I've found the answer here: https://cmake.org/cmake/help/v3.7/manual/cmake-toolchains.7.html#cross-compiling-for-android-with-the-ndk
CMAKE_ANDROID_ARCH_ABI or CMAKE_ANDROID_ARCH are similar to the ndk-build TARGET_ARCH.
CMAKE_ANDROID_ARM_MODE allows setting the ARM mode (setting it to ON targets 32-bit ARM processors, while to OFF targets 16-bit Thumb processors).
I working on android project and I need to access the wstring_convert class in c++11 in gcc but the problem is gcc does not have this in its standard library, so am thinking of using clang std library in gcc compiler of this possible, or if there is any other way to use wstring_convert from external library like stlport but stlport development latest update is in 2008 !
Any help is appreciated.
You can choose
NDK_TOOLCHAIN_VERSION := clang
in your Application.mk
The standard C++ library from the LLVM project is:
http://libcxx.llvm.org/
It is a standalone, separate project from clang, but I never heard of someone using it with GCC. There are parts of the standard library which rely on compiler-specific internals (e.g., some type traits), so I am not sure this is going to work.
edit
From the front page:
libc++ is known to work on the following platforms, using g++-4.2 and clang (lack of C++11 language support disables some functionality). Note that functionality provided by is only functional with clang.
So it looks like it might actually work with at least some versions of GCC.
I am trying to build latest FFmpeg along with halfninja's code for android since some of the options are not available in older versions.I updated FFmpeg packages and tried to run ./create_toolchain.sh.
I am getting the following error:
user#user:~/Android/android-ffmpeg-x264/Project/jni$ ./create_toolchain.sh
~/Android/android-ffmpeg-x264/Project/jni ~/Android/android-ffmpeg-x264/Project/jni
/home/user/android/tools:/home/user/android/platform-tools:/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/home/user/android/tools:/home/user/android/platform-tools:/home/user/Android/android-ndk-r8e:/home/user/Android/android-ffmpeg-x264/Project/jni/toolchain/bin
Host system 'linux-x86' is not supported by the source NDK!
Try --system=<name> with one of: linux-x86_64
My android NDK version is android-ndk-r8e.
I am facing problems in building latest version of FFmpeg by creating standalone toolchain.
Any help is appreciated.
Your system is 64 bit. The --system=linux-x86_64 should be the parameter of make-standalone-toolchain.sh which is part of the NDK. Like this:
$ANDROID_NDK/build/tools/make-standalone-toolchain.sh --system=linux-x86_64 ...
I don't know this create-toolchain.sh but I am sure there's an invocation to make-standalone-toolchain in it. That's where you have to add the parameter.
I've been working on an Android project which has several native C++ libraries. Compiling and debugging using Eclipse with ADT plugin works well. Obviously Android NDK uses arm-linux-gnueabi-gcc of some version to compile the native libraries.
Since I've been using NEON intrinsics heavily, I would like to try to compile the native libraries with ARM's official compiler armcc. I read everywhere that armcc is supposed to give better optimized code when using intrinsics. So I downloaded the trial version of DS-5 from ARM website, just to try and see whether there's really any speed difference.
The DS-5 seems to be just a modified version of Eclipse that uses the ARMCC toolchain, so I installed the ADT plugin. But when I compile using DS-5, it seems that the code is still generated using gcc rather than armcc.
Do you have any idea how to force DS-5 or Eclipse to build the Android native code using armcc? Or is it possible (and how) to build the static NDK libraries from command line and then replace the libraries in my project, so they get deployed to the testing phone?
ARM DS-5 Community Edition doesn't include ARM compiler (armcc).
If you could get hold of armcc best would be to separate your processing heavy algorithms to individual compilation units (separate C files), build them with armcc as you would do for any compilation unit. When you get the object files, convert them into an archive then use that in Android.mk as LOCAL_STATIC_LIBRARIES += <your_archive>.
You can't use armcc plainly to build Android compatible libraries mostly because of Bionic dependencies, I think.
You can use armcc to build Android compatible static libraries even though Android has a different C library (bionic). The key is the --library_interface flag for armcc. According to the documentation:
Use an option of the form --library_interface=aeabi_* when linking with an ABI-compliant C library. Options of the form --library_interface=aeabi_* ensure that the compiler does not generate calls to any optimized functions provided by the ARM C library.
In addition, there are a few more flags to ensure compatibility with the Android EABI resulting in the following command for an Android armeabi-v7a target:
armcc --library_interface=aeabi_clib --wchar32 --enum_is_int --no_hide_all --cpu=7-A --fpu=softvfp+vfpv3 -c -o libfunc.o libfunc.c
You can then use armar --create libfunc.a libfunc.o to create a static library that can be linked with the Android NDK as LOCAL_STATIC_LIBRARIES.
I have successfully tested this with Android NDK r10d on Android KitKat 4.4.2.
I'm writing ARM NEON-based code for an Android application and I was struggling with certain compiler flags not being recognized. I later realized that support for those flags was only added quite recently and that my GCC version is older. I'm doing the whole thing on Windows and am limited by what versions Cygwin has to offer. Here's my question: before I go and try to build GCC 4.6.0 on my Windows machine and make Cygwin like it, will it work for me or does the NDK use its own version of the GCC and my upgrade will not at all affect it? If it does, is it possible to tell it to use a different compiler?
Regarding NDK r8d it can be modified in 2 ways (see Andriod ndk):
For ndk-build, export the NDK_TOOLCHAIN_VERSION=4.7 variable or add it to Application.mk.
For standalone builds, add the --toolchain= option to make-standalone-toolchain.sh
--toolchain=arm-linux-androideabi-4.7
Default compiler is set in ndk/build/core/setup-toolchain.mk (see NDK_TOOLCHAIN and NDK_TOOLCHAIN_VERSION)
The NDK itself invokes a customized cross-compiler built on the arm-eabi-gcc compiler. There are examples out there of people creating custom toolchains using bog-standard GCC implementations with support for ARM instruction sets but that's way out of my league. Most of the stuff I've read in the past always discussed using the toolchain included with the NDK to compile native code.
Corollary: Most of the people who have complained and have had to make their own toolchain have been people that were upset with the (supposed) sub-par C++ support of the NDK toolchain's compiler. I can't speak to this because some of the articles were older and Android changes so rapidly. It also hasn't been an opinion that seems to pop up all too frequently.
GCC is deprecated in favor of clang as of NDK 11 (March 2016)
Mentioned on the official revision history: https://developer.android.com/ndk/downloads/revision_history.html
How to switch between compilers is asked at:
How to switch between gcc and clang in Android NDK Revision 11?
Latest C++11 features with Android NDK
And you can check it easily with:
enum CONSTEXPR {N = 256};
char s[N];
#ifdef __clang__
snprintf(s, N, "%s", "clang" __clang_version__);
#else
# ifdef __GNUC__
snprintf(s, N, "%s %d.%d.%d", "gcc", __GNUC__, __GNUC_MINOR__, __GNUC_PATCHLEVEL__);
# endif
#endif
then just log s or return it to a TextView.