Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 15 Jan 2015 20:53:21 +0700
From: Рысь <>
Subject: Re: musl and android

В Thu, 15 Jan 2015 06:01:58 -0500
Rich Felker <> пишет:

> 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.

As for now, I do not aim to make portable binaries since I do not
redistribute them (okay, I distribute them to my friends. Does that

> 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.

Do not forget about timezones in android (I forgot to mention that -

> 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 ( 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

No I am not using musl as a part of android app. I use musl in low
level C programs (relative to Java user apps) such as busybox, strace,
tcpdump, iptables, iproute2... That's why I do seek for a quick
solution now.

Android is not friendly at all, but I need to do something with it. I
want musl on it working fine, because I do want get rid of ugly android
development toolchain and it's partial libc. I completely tired of that

So, if there are no any other attempts, I can try?


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.