[Toybox] Android binaries?
enh at google.com
Wed Sep 2 10:01:05 PDT 2020
if you choose sdk_arm64 (or sdk_x86_64) off ci.android.com, click on the
little "download" icon on most recent green build (or whichever build you
want), the list of artifacts should now contain toybox-static32 and
so some human effort required (afaik there's no URL that gives you the
latest green build), but a lot less effort than building AOSP...
~/Downloads$ chmod a+x ./toybox-static64
~/Downloads$ ./toybox-static64 date
Wed Sep 2 16:44:54 GMT 2020
i'm not going to run anything else on this "real computer" or i'll be back
complaining that we should change top to not use KiB on a machine with
64GiB of RAM, and that we need to examine /proc/sys/kernel/pid_max to know
how wide pid fields need to be again :-)
On Fri, Aug 21, 2020 at 4:36 PM enh <enh at google.com> wrote:
> 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
>> 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
>> I've also had a todo item to salvage todo entries I wrote for busybox
>> ago, especially since the busybox devs crapped all over the current
>> For example,
>> used to be project-agnostic (usable advice no matter what open source
>> you were talking about), but in current
>> they've inserted a large digression in the middle about configuring
>> source from the command line to make sure it doesn't apply to any other
>> 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
>> 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
>> against musl?
>> To check if it's been fixed on _android_, they need a bionic version. (I
>> 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?
>> even if I build a bionic version with the NDK, that hasn't got all the
>> 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
>> jour, C) there's like 8 api levels for various previous releases still in
>> 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
>> 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...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Toybox