Date: Thu, 15 Jan 2015 06:01:58 -0500 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: musl and android 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
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.