[Aboriginal] Using native-build.sh for An Android native C compiler

[Rob Landley]

On 07/15/2011 03:30 PM, Earlence Fernandes wrote:
> Hello,
> 
> I plan on using aboriginal linux scripts to build a C compiler thats
> customized for Android.

Android is generally armv5l or similar, it just uses a different C
library (bionic instead of uClibc).  I note that uClibc works just fine
on android (if you either statically link or install the shared
libraries), but if you want to build everything with bionic that's fine too.

The question for a self-hosting system is do the other six packages
build with bionic?  (gcc, binutils, busybox, make, bash.  The linux
kernel won't care.)

If you're not doing a self-hosting system, it shouldn't matter much what
libc you use as long as the compiler can find it.

I gave up trying to fix the path logic in gcc years ago, instead I use a
wrapper (sources/toys/ccwrap.c) which parses the incoming gcc command
line and rewrites it to start with --nostdinc --nostdlib and then adds
in the explicit header and library paths it should search.  When it's
not a -c, -E, or -S build it explicitly adds in the libraries and .o
files necessary for linking executables.

That expects the compiler binary to be in "bin" and looks for ../include
and ../cc/include for headers, and ../lib and ../cc/lib for libraries.
In the case of linking in libc, it looks for the name "libc.so" which
should be symlinked to the C library you want to use.

> Therefore, I think these steps would be needed:
> 
> 1. download.sh to get GCC sources.

You can just populate the packages directory yourself and skip
download.sh if you like.  But sure, modifying that would work.

> 2. patch them with android specific headers and implementation

I note that sources/patches exists to apply patches to upstream
tarballs.  The extract logic will automatically apply patches with the
right names ("packagename-*.patch", the required dash is so uClibc
doesn't get uClibc++ patches applied to it).

> 3. native-build.sh for ARM

In theory that code is completely target-agnostic.  (And the actual
individual package builds are in sources/sections so they can be re-used
by the various stages as necessary.)

In practice it's not necessarily _version_ agnostic: gcc 4.2 was just
two packages, gcc 4.3 got split into four packages, and gcc 4.5 is
written in C++ so requires a different host compiler setup.

(The people who wrote gcc are completely insane, I'm really looking
forward to llvm or pcc or something becoming usable to build Linux
systems with.)

> Next, I need to optimized for space, I need it as small as possible.
> Therefore, disable CPP (with the given option),

Actually cpp is the C preprocessor (I.E. what gcc -E calls out to), you
want to disable c++.

> remove pthreads, binutils etc etc -> but how do I config this?

You can't remove binutils, it's the linker and the assembler.  (No, I
don't know why the gcc developers split the linker and assembler out
into a separate package.  I don't know why the split out GMP and MPFR in
4.3 either, but since it's GPLv3 I'm not comfortable shipping binaries
built from it so it hasn't come up.  I note that Linux From Scratch has
instructions for building those...)

> I basically need to be really lean and mean. C compiler, libc, libm,
> linux headers. thats it.

Have you looked at tinycc?  It's a working C compiler (including linker
and assembler all in one binary, busybox-style) in 100k.  Last I checked
they claimed to have basic arm support working.  (Arm on an arm host
didn't work for me, but that was 3 years ago...)

Rob