my busybox +android bionic + ndk tips, etc

[Hin-Tak Leung]

--- On Mon, 29/8/11, Tito <farmatito at tiscali.it> wrote:

> From: Tito <farmatito at tiscali.it>
> Subject: Re: my busybox +android bionic + ndk tips, etc
> To: busybox at busybox.net
> Date: Monday, 29 August, 2011, 20:40
> On Monday 29 August 2011 21:21:12
> Hin-Tak Leung wrote:
> > I have thought of filing a bug, but then there are too
> much loose information I'd like to post and probably are a
> few bug reports, so here they are: I have had a go at using
> the android ndk to build busybox against bionic, instead of
> against android source with an arm-targeted cross-gcc. (I
> think some of the recommendations online - using
> codesourcery's arm-gcc to build static, is just wrong).
> Hi,
> Why is it wrong? It is the only way to obtain a fully
> working
> busybox binary with all the functionality denied by the
> crippled
> bionic libc. You can even use Aboriginal linux (http://landley.net/aboriginal/)
> to compile it statically against uclibc for a smaller
> binary
> (or buildroot if you prefer).

It is wrong because (1) while it is probably harmless, glibc/eglibc is not bionic libc, and the kernel interfaces are probably subtly different - and you might get subtly bugs/misbehavior. (2) the binary is unnessarilly large.

This is mostly a generic criticism for statically build against one brand/version/ of libc and hoping that the result would work correctly against a different environment.

I have looked a bit and some of the missing parts or headers e.g. headers for net/ethernet.h - for ifconfig probably make sense because android also have 3G and other non-ethernet interface, so ifconfig isn't as useful and may even be misleading. (e.g. "ifconfig <everything> down" does not kill all network connectivity, say).

My point is that, I would rather have a tool that is limited in scope but work 100% correct, than one that has wider range of capability but many of the obscure corners are subtly broken.