Building C/C++ applications under KBOX

For most applications, the preferred approach for building C/C++ applications to run under KBOX is to cross-compile them on a desktop workstation (probably running Linux) using Google's Native Development Kit (NDK) tools. The NDK is essentially a build of GNU gcc configured for Android.

In fact, there really aren't many good reasons for hacking on C code on an Android device -- generally these devices are slow (compared to a desktop computer), and have inadequate screens and keyboards. However, there are some applications that, even in these enlightened times, are difficult or impossible to cross-compile. Perl is a good example: cross-compiling Perl for Android is a brain-bendingly unpleasant task. By building these applications directly on the device, we turn a cross-compilation problem into a regular compilation problem, albeit probably still a very difficult one (largely because of all the limitations in the Android standard C library.)

In addition, for educational purposes, people have expressed an interest in having a way to fiddle with simple C applications whilst standing packed shoulder-to-shoulder on the train in the morning rush-hour.

Whatever the reason, KBOX has a build of gcc, version 4.9.2 (contributed by Cyd Hasleton), and the usual GNU utilities like make. It's certainly possible to build substantial applications like Python or Perl directly on the device, although it may take some time.

The gcc package is available on the Downloads page, and can be installed using dpkg -i in the usual way. The compiler installs primarily in /usr/gcc-4.9-pie, although some libraries are installed in /usr/lib. The utilties /usr/bin/gcc, /usr/bin/g++, and /usr/bin/cpp are actually scripts, which run the binaries with particular command-line arguments. In some situations it will be necessary to invoke gcc explicitly as /usr/gcc-4.9-pie/bin/gcc, and specify different arguments, as will be discussed. However, if you're just compiling "Hello, world," then this should do the trick:

kbox$ gcc -o hello hello.c
This is exactly the same invocation that ought to work on a desktop PC.

When running gcc this way, it is actually invoked like this:

kbox$ /usr/gcc-4.9-pie/bin/gcc -fPIC -fPIE -pie --sysroot=/usr/gcc-4.9-pie/sysroot -o hello hello.c
The various "PI" flags tell the compiler to produce position-independent code. For various reasons -- none of which repay detailed scrutiny -- Google has insisted on this for Android 5 and later. You'd have to specify these arguments when building on a desktop PC with the NDK as well.

The sysroot argument indicates where gcc should look for its standard directories like /usr/include and /usr/lib. I have packaged gcc with these directories separate from the conventional places because I've encountered incompatibilities if libraries like are placed into the system /usr/lib directory. These sysroot libraries are only used by the gcc linker -- at runtime the standard Android Bionic libraries are used. So, apart from creating an odd filesystem layout compared to a desktop workstation, there's no disadvantage to keeping gcc's versions of standard libraries separate from system versions. However, some automated build utilities do insist on knowing where C/C++ header files actually are and, in this package, they are in /usr/gcc-4.9-pie/sysroot/usr/include.

On some systems, both compiling and linking produce warning messages of the form "WARNING: unused DT entry..." I do not know why this happens, but so far the messages seem to be harmless.

Please bear in mind that this implementation of gcc will produce applications that run under KBOX and, specifically, use the standard C library (BIONIC) provided by Android. This library is limited compared to a desktop C library like glibc, but is a better match (for the most part) for Android, which is a limited version of Linux. Most non-trivial applications will need changes -- often substantial changes -- to build on Android. These changes are not necessitated simply by the different C library, but by Android's unconventional security model, unconventional filesystem layout, odd use of user and group IDs, lack of common Linux system services, undocumented and proprietary audio API, etc., etc. Building under KBOX, rather than raw Android, conceals some of these limitations, but by no means all of them.