[Toybox] Android binaries?

[enh]

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
toybox-static64.

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
>> 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/20200902/bfa8e5d6/attachment.htm>