Android-NDK ships its own compiler to build the native code. The version shipped with my current android-NDK installation is arm-linux-androideabi-g++ (GCC) 4.6.x-google 20120106 (prerelease), I guess it's a fork of GCC 4.6.
What are the differences between it and a regular (vanilla) GCC 4.6? Is it producing better code for ARM platforms?
I'd like to use other compilers to build software for android, like vanilla GCC 4.7 or Clang, since they have a better support of C++11 and implement some features I'm struggling to use (like template aliases).
Is it possible to use the latest vanilla GCC or Clang, to build the native code for Android? What parameters should I use?
What are the cons of using a compiler different from the one shipped with android-SDK?
Android GCC is customized for the android as all the features in the GCC are not supported by the native Android. I dont think there is a possibility, you can post the same in the android ndk google groups where your answers will be replied by the Google Android Developers.
They were suggesting that we can make use of the cross compilers for compiling the android code with out using the android ndk.
Just a heads-up: google added clang3.1 in Revision 8c of the Android NDK. It's in "experimental" stage now, but easy to try out (and probably will be better supported in the near future, hopefully with a proper port of libc++, too).
Related
I'm primarily a C developer who has been tasked with building some C libraries into shared object files that can be built into an Android app. I came across this link which discusses how to add a prebuilt library to an Android Studio project, but very little information on how to actually build a prebuilt library. I did find information saying I can't just use Linux cross-compilers to do so due to slight differences in ABI. How would I go about doing this? Do I need to use Android Studio? Do my sources need to include some special header? Or can I just use the cross compilers found in the NDK and compile using gcc -shared -fPIC?
It's enough to build your library with an NDK toolchain. Usually it's OK to use the lowest platform API level supported by NDK. You should produce the binaries for different CPUs. You may skip the 32-bit variants if you wish, but the rules of Android Play Store require that you have a 64-bit version. You don't need Android Studio for this task, and no changes to your sources are necessary.
If your library exports C++ API, use c++_shared runtime.
I want to embed Antlr4.8 C++ runtime lib in our App which supports Android 4.4.
I have checked the official Google Doc about NDK, but still don't know the relationship between NDK version and Android System version and C++ version.
So can anyone give me some tip or "more detail" Doc about embed C++11 lib in Android App?
Thanks.
By the way, i am an iOS developer so this is difficult for me and i still try hard to learn Android NDK development.
According to release notes of the current Android NDK v21, the toolchain uses Clang release r365631 (the master branch as of 10 July 2019), which corresponds to Clang 9.0.6.
That means that C++ is supported all the way up to C++17, and even some parts of C++20.
So C++11 is no problem at all.
Note: to use the latest C++17 features, you might have to link with the latest libc++ statically (-static-libstdc++), as explained here. For C++11 this most likely won't be needed.
According to the source and wiki, Titanium requires r9 of the Android NDK. But in the Android archives, the oldest version available is r10e (May 2015). The current version is r14b.
With r14b (and r13b) I get compilation failures from ndk-build involving a C++ type mismatch.
[ERROR] /Users/jdee/Library/Application Support/Titanium/mobilesdk/osx/6.1.0.GA/android/native/include/AndroidUtil.h:57:49: warning: format specifies type 'int' but the argument has type 'long' [-Wformat]
I can compile a module cleanly using r10e, r11c and r12b, but I'm hesitant to release something with an unsupported NDK version. It seems strange that Titanium requires a version of NDK from 2014 as well. I'm not sure which version to use.
As of today, the same wiki page speaks of NDK r12, which can be downloaded from the official archive. The drawbacks of using an older NDK are, outweighed by the risks of relying on tiny nuances of compiler compatibility. It would require exhaustive testing on a wide range of supported devices to prove that your build with NDK r16 is OK. And note that upgrading NDK requires some fixes, see https://github.com/appcelerator/titanium_mobile/pull/9926.
As long as you don't need the native APIs that are specific for Oreo and higher, you can use r12 without fear.
If your project involves other NDK components that cannot be built with NDK r12, please remember that you can mix shared libraries built separately (with different NDK versions) in one app, as long as they do not share C++ objects between them. Titanium v8 framework is safe is this sense.
One point of weakness here is the shared STL runtime libc++_shared.so. You cannot have two different versions of it in your app. Probably the safest solution for such situation is to change the Titanium Application.mk file to use
APP_STL := c++_static
I'm fascinated by the Pure algebraic/functional language. The Pure interpreter uses the LLVM JIT compiler as its backend.
I would like to compile Pure so that it runs on Android(ARM). Pure has a dependency on the LLVM JIT. So I need to compile LLVM source for Pure to run.
Is it possible to compile LLVM source for Android (ARM) devices? There really seems to be no information about this on the web. Maybe my search terms are wrong. Searching for Android LLVM does not bring up many good hits either.
It now seems possible, the NDK now supports Clang which uses LLVM. So maybe it can be made to work with any LLVM language. AOSP should give us some insight on how they added Clang support. See the latest Android NDK for details on Clang support.
Android NDK, Revision 8c (November 2012)
Important changes:
Added the Clang 3.1 compiler to the NDK. The GNU Compiler Collection (GCC) 4.6 is still the default, so you must explicitly enable the Clang compiler option as follows:
For ndk-build, export NDK_TOOLCHAIN_VERSION=clang3.1 or add this environment variable setting to Application.mk.
For standalone builds, add --llvm-version=3.1 to make-standalone-toolchain.sh and replace CC and CXX in your makefile with /bin/clang and /bin/clang++. See STANDALONE-TOOLCHAIN.html for details.
Note: This feature is experimental. Please try it and report any issues.
While you can surely compile LLVM on ARM (it's pretty trivial - just ordinary configure + make system), you're still out of luck: JIT on ARM is still work-in-progress, so I'd not expect it working for everything non-trivial.
It seems like the Android NDK would help in this, as one of its usages per its FAQ page is to reuse C/C++ code.
I think we shuld see on mix of LLVM + Android NDK (C++).
I'm thinking about SmallTalk-like dymanic object system (*), and LLVM usage is very interesting for lazy dynamic compilation on Android devices.
First try you shuld build something like tiny Buildroot/OpenWrt Linux system (or build you own using CLFS or my scripts: https://github.com/ponyatov/L/tree/clock )
for ARM device like Raspberry Pi (it's my case for testing). If you got good results on this variant, later you can migrate to Android device itself. I think you'll need some C++/NDK glue code to adopt LLVM/Pure core vs Android runtime and GUI. (**)
(*) but with my own language syntax, lisp-like functional abilities to mutate all system internals, parser/compiler integrated framework, and maybe some basics of symbolic computer algebra
(**) is Android Pi alive ?
As far as I know you can't build LLVM for ARM devices just yet.
the Android ndk is hard to use for the old autoconf based code, so i employed scratchbox2/emdebian to have a complete build environment. can i build a shared library in emdebian (arch is armel) and then use it in android?
The official NDK comes with a version of GCC that works with Google's custom Bionic libc. If you are using a version of GCC that is intended to work with the GNU libc then you must statically link it in (as is done by the Crystax NDK). So even if your compiler generates the correct instructions, it may be worthwhile to rework your build environment to avoid bloating your application unnecessarily.
armel is Arm Eabi. Android is ARMv5 eABI. They will probably be compatible.