<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Aug 23, 2020 at 9:45 PM Rob Landley <<a href="mailto:rob@landley.net">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">On 8/21/20 6:36 PM, enh wrote:<br>
> <br>
> <br>
> On Thu, Aug 20, 2020 at 3:57 AM Rob Landley <<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a><br>
> <mailto:<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>>> wrote:<br>
> <br>
>     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>
> <br>
> the "build a static toybox" part did, but the "add it to the artifacts" part<br>
> didn't. the NDK guy -- who spends 99% of his time with old devices and other<br>
> people also stuck on old devices -- liked the idea but the build guy -- who<br>
> actually gets the bill for storage -- was less excited.<br>
<br>
I've commented before that AOSP shipping dynamically linked prebuilt binaries is<br>
one of those "so close, yet so far" things...<br></blockquote><div><br></div><div>for the host binaries? yeah, static would certainly help some people, but as long as we're using glibc for the host...</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.) <br>
> <br>
> yeah, i don't know --- Android's seccomp system call filter is pretty narrow and<br>
> doesn't cover all of the "legacy" system calls that musl probably uses. i<br>
> suspect arm32 musl doesn't work at all, but arm64 musl might mostly work?<br>
<br>
Rich is fastidious about only using new syscalls when he can get away with it,<br>
and keeping the set of used syscalls to a minimum. I'd have to ask him what the<br>
actual set he's using is though.<br>
<br>
But mostly I was thinking that when trying to reproduce a bug, swapping out the<br>
libc probably shouldn't be part of the standard reproduction sequence. Even when<br>
the bug isn't in libc, what will/won't trigger it can change.<br>
<br>
>     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>
> <br>
> the long term fix is just to get toybox into a mainline module along with libc.<br>
> but that's not happening this year or next.<br>
> <br>
> i'll see if i can work out how to tell <a href="http://ci.android.com" rel="noreferrer" target="_blank">ci.android.com</a> <<a href="http://ci.android.com" rel="noreferrer" target="_blank">http://ci.android.com</a>><br>
> that toybox-static32 and toybox-static64 should only be in ndk builds...<br>
<br>
I make generally enthusiastic noises, with only the vaguest idea of what that<br>
means in context. Yay, doing the thing.<br>
<br>
Rob<br>
<br>
P.S. If you're talking about space consumed by AOSP prebuilts I have various<br>
suggestions, but that seems more a political can of worms than a technical one?<br>
I don't know the context/constraints they're working under.<br></blockquote><div><br></div><div>not prebuilts, _builds_. every build that the build bots build is kept. (exactly how long depends on exactly what kind of build. obviously some are more important than others.)</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">
For example "why are you shipping 2 megs of<br>
prebuilts/gcc/linux-x86/x86/x86_64-linux-android-4.9/bin/x86_64-linux-android-ld.bfd<br>
when ld links to .gold instead" is preceded by </blockquote><div><br></div><div>depending on what you're doing, you might be using bfd, gold, or lld. lld arrived before we'd managed to get everyone over to gold. lld is good enough for the platform at this point but the NDK still hasn't moved, and the NDK is trickier because we don't control all the code/build systems people are using.</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">"why are you shipping gcc when<br>
llvm deprecated it and it was supposedly removed" which is preceded by</blockquote><div><br></div><div>for kernel builds. we're part way through the multi-year deprecation/removal: <a href="https://android-review.googlesource.com/c/platform/prebuilts/clang/host/linux-x86/+/1405387/3/BINUTILS_KERNEL_DEPRECATION.md#5">https://android-review.googlesource.com/c/platform/prebuilts/clang/host/linux-x86/+/1405387/3/BINUTILS_KERNEL_DEPRECATION.md#5</a></div><div><br></div><div>(it has been removed from the NDK.)</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"> "why does<br>
the x86 directory have a mips directory next to it when I thought you end of<br>
lifed that platform"... The dates on the mips files are may 6 2019 and I<br>
downloaded this whole thing fresh in something like february...? I'm sure<br>
there's a reason, but dunno what it is.<br></blockquote><div><br></div><div>because it's already hard enough to build an old binutils (especially on new macOS) and the risk/reward of changing it to not build mips binaries that aren't used anyway just isn't worth the trouble.</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">
If the NDK guys are interested in experiments to save space,</blockquote><div><br></div><div>the OS build is the issue here, not the NDK build.</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 note that<br>
building an x86-64 targeted compiler as static i686 binaries linked against musl<br>
can be SMALLER than dynamically native x86-64 binaries, and sometimes runs<br>
faster (due to lighter cache footprint and less memory bus bandwidth for the<br>
data structures) and does not require any :i386 packages installed to run<br>
because static liking. I haven't tried it with llvm but I don't see why it<br>
wouldn't work?<br></blockquote><div><br></div><div>iirc, thanks to Windows not having symlinks, having to ship N copies of all the libraries means that compiler size is in the noise anyway :-(</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 did this crap for YEARS in aboriginal, and I still beat similar weirdness out<br>
of musl with mcm-buildall.sh, which has:<br>
<br>
  # All toolchains after the first are themselves cross compiled (so they<br>
  # can be statically linked against musl on the host, for binary portability.)<br>
  # static i686 binaries are basically "poor man's x32".<br>
  BOOTSTRAP=i686-linux-musl<br>
<br>
near the start. :)<br>
<br>
Rob<br>
</blockquote></div></div>