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.
Related
I built a library(.so) that is being called from JNI code in some android app. The JNI code is built using NDK.
If I build the library using android tool-chain, the library works well when called from JNI code.
If I build the library using another tool-chain (used on the same ARM device for none android applications), the library crashes when called from JNI code.
why do we need to use android tool-chain (or NDK) for compiling c/c++ code running in the context of an android app? why not use other tool-chains?
You can use other toolchains, but it requires special care.
Maybe a good starter would be to learn the UBERTC and Linaro Wiki.
The main difference is that NDK compilers are tuned for bionic (Android variant of C runtime libraries). Originally, bionic was a modest subset of Linux runtime. On latest platforms, most of the gap is closed, but now there are many extensions that you probably need.
Also, Android dynamic linker may require (depending on target platform) a set of ELF flags that are automatically delivered by NDK binutils, like PIC, id, and others.
It is quite possible to use arm-linux toolchain to build a statically linked executable that will run on Android, but for a library that must play well on the JNI environment the effort is probably not worth it.
Note that NDK provides tools to create a standalone toolchain, which behaves very similar to other toolchains you may be familiar with. This approach makes it easy to adopt 3rd-party libraries with sophisticated build scripts.
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
Applications for Android devices are written in Java. I also know of the existence of the NDK (Native Development Kit).
I have a library written in C++ that uses:
stl containers
c++ i/o (streams etc..)
memory allocation/deallocation using new etc...
Are all this things available to the programmer that want to use the NDK for C++ development?
I am confident that memory alloc and stl are there, but what about I/O from files? Can i use istream/ostream? I ask because i have programmed apps on Symbian and i had to use RFile and other classes (there was no support for fopen/fread etc).
Yes, low level I/O is possible. fopen/fread are available from the first NDK release.
istream/ostream are available since NDK r5 when STLport and GNU stl were added.
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.