[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150115205321.5afdf0eb@sibserver.ru>
Date: Thu, 15 Jan 2015 20:53:21 +0700
From: Рысь <lynx@...server.ru>
To: musl@...ts.openwall.com
Subject: Re: musl and android
В Thu, 15 Jan 2015 06:01:58 -0500
Rich Felker <dalias@...c.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.
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)
>
> 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
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.
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.
