From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6841 Path: news.gmane.org!not-for-mail From: =?UTF-8?B?0KDRi9GB0Yw=?= Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl and android Date: Thu, 15 Jan 2015 20:53:21 +0700 Message-ID: <20150115205321.5afdf0eb@sibserver.ru> References: <20150115161322.4ee903b7@sibserver.ru> <20150115110158.GN4574@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1421329658 18461 80.91.229.3 (15 Jan 2015 13:47:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 15 Jan 2015 13:47:38 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6854-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jan 15 14:47:34 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YBklp-0004sX-Kr for gllmg-musl@m.gmane.org; Thu, 15 Jan 2015 14:47:33 +0100 Original-Received: (qmail 15408 invoked by uid 550); 15 Jan 2015 13:47:27 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 15397 invoked from network); 15 Jan 2015 13:47:26 -0000 X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,NO_RECEIVED, NO_RELAYS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 In-Reply-To: <20150115110158.GN4574@brightrain.aerifal.cx> X-Mailer: claws-mail Xref: news.gmane.org gmane.linux.lib.musl.general:6841 Archived-At: =D0=92 Thu, 15 Jan 2015 06:01:58 -0500 Rich Felker =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > On Thu, Jan 15, 2015 at 04:13:22PM +0700, =D0=A0=D1=8B=D1=81=D1=8C wrote: > > Hello all! > >=20 > > Are there any efforts or even a project which aims to port musl to > > android platform? > >=20 > > 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: > >=20 > > + Proper DNS resolving is not available > > + Translation of android special user names is not done > >=20 > > 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. > >=20 > > Because I am not going beyond listed items, a patch can be developed > > just to support these inside musl-linked binaries. > >=20 > > I am first here or there is already someone who done this before? >=20 > Hi, >=20 > 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 count?) > 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 - sorry) >=20 > 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. >=20 > 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... :( >=20 > 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 environment. So, if there are no any other attempts, I can try? Thanks.