<div dir="ltr">if you choose sdk_arm64 (or sdk_x86_64) off <a href="http://ci.android.com">ci.android.com</a>, 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.<div><br></div><div>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...</div><div><br></div><div>~/Downloads$ chmod a+x ./toybox-static64 <br></div><div>~/Downloads$ ./toybox-static64 date<br>Wed Sep  2 16:44:54 GMT 2020<br></div><div><br></div><div>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 :-)</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 21, 2020 at 4:36 PM enh <<a href="mailto:enh@google.com">enh@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 20, 2020 at 3:57 AM Rob Landley <<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">You said way back when that you were thinking of putting up downloadable current<br>
toybox android-built binaries somewhere. Did that ever happen?<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I'm writing a "reporting bugs" FAQ entry because of the recent github thread.<br>
<br>
I've also had a todo item to salvage todo entries I wrote for busybox forever<br>
ago, especially since the busybox devs crapped all over the current versions.<br>
For example,<br>
<a href="https://git.busybox.net/busybox/tree/docs/busybox.net/FAQ.html?h=95718b309169#n361" rel="noreferrer" target="_blank">https://git.busybox.net/busybox/tree/docs/busybox.net/FAQ.html?h=95718b309169#n361</a><br>
used to be project-agnostic (usable advice no matter what open source project<br>
you were talking about), but in current <a href="https://busybox.net/FAQ.html#backporting" rel="noreferrer" target="_blank">https://busybox.net/FAQ.html#backporting</a><br>
they've inserted a large digression in the middle about configuring busybox<br>
source from the command line to make sure it doesn't apply to any other project<br>
and can't be generally referenced as advice by other projects.<br>
<br>
But anyway, the advice was "try to reproduce the bug on a current version before<br>
poking the developers because there's a nonzero chance we already fixed it", and<br>
for linux toybox I can point them at<br>
<a href="https://landley.net/toybox/downloads/binaries" rel="noreferrer" target="_blank">https://landley.net/toybox/downloads/binaries</a> for current versions (even if they<br>
don't want to build it from source for their target)... but those are linked<br>
against musl?<br>
<br>
To check if it's been fixed on _android_, they need a bionic version. (I mean<br>
the musl versions will run but all sorts of subtle behavior's different.) </blockquote><div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">And<br>
even if I build a bionic version with the NDK, that hasn't got all the libraries<br>
the AOSP build uses. And the AOSP build here 1) takes FOREVER,  B) is random git<br>
snapshot du jour, bundling one with MY releases doesn't sync up with YOUR<br>
releases in any useful way and could be broken because of transient fluff du<br>
jour, C) there's like 8 api levels for various previous releases still in use<br>
that I have no idea how to beat out of current AOSP source anyway, D) me<br>
distributing android binaries seems like a layering violation somehow. I do not<br>
have the domain expertise to properly support or secure them beyond what I'm<br>
already doing.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>i'll see if i can work out how to tell <a href="http://ci.android.com" target="_blank">ci.android.com</a> that toybox-static32 and toybox-static64 should only be in ndk builds...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Anyway, just wondering...<br>
<br>
Rob<br>
</blockquote></div></div>
</blockquote></div>