[Toybox] Android binaries?

[enh]

On Thu, Aug 20, 2020 at 3:57 AM Rob Landley <rob at landley.net> wrote:

> You said way back when that you were thinking of putting up downloadable
> current
> toybox android-built binaries somewhere. Did that ever happen?
>

the "build a static toybox" part did, but the "add it to the artifacts"
part didn't. the NDK guy -- who spends 99% of his time with old devices and
other people also stuck on old devices -- liked the idea but the build guy
-- who actually gets the bill for storage -- was less excited.


> I'm writing a "reporting bugs" FAQ entry because of the recent github
> thread.
>
> I've also had a todo item to salvage todo entries I wrote for busybox
> forever
> ago, especially since the busybox devs crapped all over the current
> versions.
> For example,
>
> https://git.busybox.net/busybox/tree/docs/busybox.net/FAQ.html?h=95718b309169#n361
> used to be project-agnostic (usable advice no matter what open source
> project
> you were talking about), but in current
> https://busybox.net/FAQ.html#backporting
> they've inserted a large digression in the middle about configuring busybox
> source from the command line to make sure it doesn't apply to any other
> project
> and can't be generally referenced as advice by other projects.
>
> But anyway, the advice was "try to reproduce the bug on a current version
> before
> poking the developers because there's a nonzero chance we already fixed
> it", and
> for linux toybox I can point them at
> https://landley.net/toybox/downloads/binaries for current versions (even
> if they
> don't want to build it from source for their target)... but those are
> linked
> against musl?
>
> To check if it's been fixed on _android_, they need a bionic version. (I
> mean
> the musl versions will run but all sorts of subtle behavior's different.)


yeah, i don't know --- Android's seccomp system call filter is pretty
narrow and doesn't cover all of the "legacy" system calls
that musl probably uses. i suspect arm32 musl doesn't work at all, but
arm64 musl might mostly work?


> And
> even if I build a bionic version with the NDK, that hasn't got all the
> libraries
> the AOSP build uses. And the AOSP build here 1) takes FOREVER,  B) is
> random git
> snapshot du jour, bundling one with MY releases doesn't sync up with YOUR
> releases in any useful way and could be broken because of transient fluff
> du
> jour, C) there's like 8 api levels for various previous releases still in
> use
> that I have no idea how to beat out of current AOSP source anyway, D) me
> distributing android binaries seems like a layering violation somehow. I
> do not
> have the domain expertise to properly support or secure them beyond what
> I'm
> already doing.
>

the long term fix is just to get toybox into a mainline module along with
libc. but that's not happening this year or next.

i'll see if i can work out how to tell ci.android.com that toybox-static32
and toybox-static64 should only be in ndk builds...


> Anyway, just wondering...
>
> Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20200821/55a22307/attachment-0001.htm>