Re: musl and android

[Rich Felker <dalias@libc.org>]

On Thu, Jan 15, 2015 at 04:13:22PM +0700, Рысь wrote:
> Hello all!
> 
> Are there any efforts or even a project which aims to port musl to
> android platform?
> 
> For a year I slowly had built and running a couple of C tty only
> programs such as iptables, tcpdump and of course busybox and many
> others including my own with musl libc linked statically. They work
> perfectly (no much differences between an ARM phone and, for example,
> raspberry pi SoC) but a few items I missed:
> 
> + Proper DNS resolving is not available
> + Translation of android special user names is not done
> 
> As an advanced Linux user I know that android is not friendly enough to
> plain C stuff and it's libc is even not finished now so I aimed to port
> at least listed things to musl.
> 
> Because I am not going beyond listed items, a patch can be developed
> just to support these inside musl-linked binaries.
> 
> I am first here or there is already someone who done this before?

Hi,

The above issues are complicated by the fact that musl aims to produce
binaries that work anywhere and that follow existing practice rather
than inventing new mechanisms -- a principle which Android ignored or
even treated with hostility.

Supporting alternate passwd/group backends is an open agenda item, but
the proposed methods we're looking at are still not really "Android
compatible". Same goes for DNS -- the recommended way to do alternate
name resolver backends is a local nameserver, but that's not very
friendly to the Android setup either.

I'm not sure what the best approach here is. Perhaps it's to treat
Android as a new body of existing practice and also support the
gratuitously-different Android things inline in the same binaries.
This seems ugly but perhaps preferable to having multiple incompatible
targets.

For now, the easiest way to deploy musl on Android (by this, I mean as
part of an Android app) seems to be including your own, possibly
patched, copy of the dynamic linker (libc.so/ld-musl) in the package
and executing the program via a wrapper script that manually invokes
the dynamic linker (so the hard-coded PT_INTERP pathname isn't
needed). Or of course static linking works (with similar patching if
necessary). But these are not the approaches I'd like to be
recommending in the long term... :(

Rich