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