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 <e...@google.com> wrote: > > > On Thu, Aug 20, 2020 at 3:57 AM Rob Landley <r...@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 >> >
_______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net