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.
Related
With google deprecating GCC, Qt 5.12 for Android makes a transition away from it in favor of Clang. Which renders the existing building guides obsolete, as they are all GCC based.
The stock Qt build for Android is lacking some important functionality, and furthermore, the related documentation seems to be fairly outdated.
Additionally, 5.12 launches with a critical Android related bug, which pretty much mandates a custom build to incorporate the fix for the time being.
I myself haven't previously used Clang at all, and I am one of those people who really prefer to just make applications rather than to go through the often excruciatingly frustrating experience of trying to build the requisite tools.
Qt on Clang is here to stay, and 5.12 being a long term support release, I think a detailed step by step guide how to produce a working Qt build will be of benefit to a lot of people. It would definitely save me days of headaches and setbacks, and so I am willing to offer a generous bounty to the first reproducible answer, in addition to any bounties that may be required to promote the question visibility.
My personal requirements are SSL, MySQL and PostgreSQL support, although additional functionality is welcome. It would seem that a Linux based guide will be the most beneficial format, as it is also applicable to windows via MSYS.
I can't reply for all your requests, but I can say something about openssl:
Firstoff, even with Qt 5.12, if you are using the official android builds downloaded from Qt itself (via the Maintenancetool), then you still have to use the gcc toolchain and openssl 1.0.2. The Qt builds require 1.0.* and clang support has only been added to openssl since 1.1.1. Support for this version of openssl will hopefully come with Qt 5.13. See QTBUG-71391 for more details.
That beeing said, if you cross-compile Qt for Android yourself (or visit this post in the future, when Qt supports this), you can use openssl 1.1 and use clang to compile it.
The steps are documented on their github in NOTES.ANDROID. The steps are relatively straight forward and boil down to a few changes to PATH in order to build the library. A basic script, with switches for all android architectures provided by Qt, would be:
TOOLCHAIN_VERSION=4.9
HOST_ARCH=linux-x86_64
case "$ANDROID_TARGET_ARCH" in
arm64-v8a)
API_VERSION=21
ARCH_ID=android-arm64
TOOLCHAIN=aarch64-linux-android-$TOOLCHAIN_VERSION
;;
armeabi-v7a)
API_VERSION=16
ARCH_ID=android-arm
TOOLCHAIN=arm-linux-android-$TOOLCHAIN_VERSION
;;
x86)
API_VERSION=16
ARCH_ID=android-x86
TOOLCHAIN=x86-$TOOLCHAIN_VERSION
;;
*)
echo "Unsupported ANDROID_TARGET_ARCH: $ANDROID_TARGET_ARCH"
exit 1
;;
esac
export ANDROID_NDK=/path/to/ndk
export PATH=$ANDROID_NDK/toolchains/llvm/prebuilt/$HOST_ARCH/bin/:$ANDROID_NDK/toolchains/$TOOLCHAIN/prebuilt/$HOST_ARCH/bin:$PATH
./Configure $ARCH_ID shared no-ssl3 -D__ANDROID_API__=$API_VERSION
make SHLIB_VERSION_NUMBER= SHLIB_EXT=.so build_libs
In this script, ANDROID_TARGET_ARCH is simply the value of the qmake variable with the same name, so this script could be invoked by qmake. The steps that need to be done in detail are:
Prepare some variables:
TOOLCHAIN_VERSION: Simply the version of the gcc toolchain to be used (yes, this is still needed, as some tools, linke ranlib etc. are still used from there). As of NDK v18 the toolchain version is still 4.9
HOST_ARCH: The architecture of the host system. The sample sets this to linux. If you are on window/macos adjust this accordingly.
API_VERSION: The Android SDK version openssl should build for. I set the values to the version that Qt uses for builds for these plattforms, but other versions should be fine as well
ARCH_ID: The name of the android architecture as used by openssl
TOOLCHAIN: The name of the gcc toolchain to be used
Ensure the ANDROID_NDK environment variable is set to wherever you installed the NDK
Update the path to contain both, the clang/llvm toolchain and the gcc toolchain for your specific plattform. In the script, the locations of the toolchains are derived from the previous variables
Explicitly run the Configure script - and not config. Pass the target architecture and additional flags. (I for example prefer to disable ssl3 for security reasons)
Run make to build the library. The SHLIB_VERSION_NUMBER= SHLIB_EXT=.so part is needed to ensure that the binaries created do not have a version number as part of their name, as android does not support that.
And thats it!
Does Android support splice() and sendfile()?
These are Linux kernel calls, so they do exist on Android.
The more interesting question is if Bionic libc provides wrappers as it does for most ordinarily used system calls, or if you will have to invoke them directly. Additionally, apart from being included in Bionic there is the question of the functionality being exported for general use in the NDK.
It appears that sendfile() has been there since the first NDK release.
splice() has not historically seemed to be part of the NDK (I did not check the latest), though it was added to the AOSP sources of Bionic libc in June 2014.
Incidentally grep -r on relevant parts of the NDK installation and/or an AOSP Bionic checkout is a quick way to look into things like this.
Ndk doesn't support splice(). When I was trying to compile dirtypipe exploit for android.
Trying to port a Delphi library to Android. Free Pascal has Android/ARM support - a prebuilt compiler for Windows is available. However, Android NDK now supports MIPS and x86 as well. What's the status of support for those in FPC? For now, my project is more or less CPU agnostic - the native bits are built for all four supported architectures. Don't want to let go of that.
I'm not after the full cycle of Android development in Pascal - just an algorithm library that does no I/O. I tried translating it into C with p2c, but the translator chokes on the sources.
Should I just try and build cross-compiler for the relevant CPU with Linux, and then link against the NDK libraries?
EDIT: I've built the cross-compiler for Intel/Linux from the sources of the Android branch. It works, except you have to invoke ppcross386 to compile, not fpc. The latter, it seems, ignores the -Tlinux option and invokes the Intel/Win32 compiler.
EDIT2: with a small change to the makefile and sources, the MIPS cross-compiler builds. However, as building moves on to the cross-CPU RTL, it errors out almost right away.
EDIT, finally: support for Android/MIPSEL compilation target is available in the FPC trunk. Export the latest, build the crosscompiler, code away.
While support for MIPS ISA can be found here and there in the FP sources, it's not officially done yet. Waiting for the 2.7 release.
In the meantime, there's support for compiling to Java bytecode in the trunk, it's documented in the FP wiki. Maybe I can leverage that as a stopgap...
EDIT: Free Pascal over JVM works in general on Android, but its rules are somewhat different from regular Pascal. Otherwise correct Pascal conks out when compiled to JVM. So it's unfit for porting large bodies of legacy Pascal code that was not written with JVM in mind in the first place.
EDIT: I got my FPC project working on MIPS/Android, but my recipe is not fit for general consumption, because the scope of Pascal RTL usage in my project is very limited. It involves cross-compiling from Pascal to MIPS assembly (targeting MIPSEL/Linux, available in the FPC trunk), then feeding the generated assembly sources to the NDK build system, providing along a C/assembly reimplementation of a limited subset of Pascal RTL.
The whole body of Pascal RTL is big and scary. My solution, which involves reimplementing the Pascal RTL in C from scratch, is, well, the opposite of generally applicable.
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).
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.