[Toybox] NDK versions?

[enh]

On Fri, Mar 8, 2019 at 12:34 PM Rob Landley <rob at landley.net> wrote:
>
> On 3/8/19 1:06 PM, enh wrote:
> > On Fri, Mar 8, 2019 at 10:47 AM Rob Landley <rob at landley.net> wrote:
> >>
> >> On 3/5/19 6:23 PM, Rob Landley wrote:
> >>> landley at halfbrick:~/toybox/clean$
> >>> CROSS_COMPILE=/home/landley/android/android-ndk-r19b/toolchains/llvm/prebuilt/linux-x86_64/bin/llvm-
> >>> LDFLAGS=--static make
> >>
> >> It took some squinting (and rereading the instructions on the website multiple
> >> times... why does the
> >> android-ndk-r19b/toolchains/x86_64-4.9/prebuilt/linux-x86_64/bin/ directory
> >> exist again? There's no cc in there.)
> >
> > that's binutils. we're working on moving over to the llvm tools, but
> > binutils isn't going to disappear for a while. the OS already switched
> > for the most part, but that's a subset of all NDK uses (and mostly
> > under our control if there's a workaround).
>
> I am currently sitting about 5 feet from the maintainer of ellcc.org (last day!)
> and have frowned at him over the cubicle divider, and cc'd his home email.
>
> (It's tangential, but he did a toolchain using _all_ the bsd licensed stuff but
> hasn't cleaned up his repo into a clean "tarball+patches" thing and hasn't
> gotten a new release out in forever.)
>
> Ah, day jobs...
>
> >> But this worked:
> >>
> >> mkdir ~/android
> >> cd ~/android
> >> wget https://dl.google.com/android/repository/android-ndk-r19b-linux-x86_64.zip
> >> unzip android-ndk-r19b-linux-x86_64.zip
> >> ln -s x86_64-linux-android28-clang
> >> android-ndk-r19b/toolchains/llvm/prebuilt/linux-x86_64/bin/x86_64-linux-android-cc
> >>
> >> cd ~/toybox
> >> CROSS_COMPILE=~/android-ndk-r19b/toolchains/llvm/prebuilt/linux-x86_64/bin/x86_64-linux-android-
> >> LDFLAGS=--static make distclean defconfig toybox
> >>
> >> I should stick some variant of that in the FAQ page.
> >
> > maybe with a note saying that "28" should be replaced by whatever the
> > current highest API level is (since you're getting a static libc.a
> > anyway).
>
> The URL isn't stable either. And I forgot to put the /android/ dir in the
> CROSS_COMPILE above (cut and pasted from two different attempts).
>
> > if you use 10000 (internally used to mean "current unreleased OS")
> > instead of 28 does that work?
>
> Alas, no:
>
> landley at halfbrick:~/android/android-ndk-r19b/toolchains/llvm/prebuilt/linux-x86_64/bin$
> ls x86_64-linux-android[0-9]*
> x86_64-linux-android21-clang    x86_64-linux-android24-clang++
> x86_64-linux-android21-clang++  x86_64-linux-android26-clang
> x86_64-linux-android22-clang    x86_64-linux-android26-clang++
> x86_64-linux-android22-clang++  x86_64-linux-android27-clang
> x86_64-linux-android23-clang    x86_64-linux-android27-clang++
> x86_64-linux-android23-clang++  x86_64-linux-android28-clang
> x86_64-linux-android24-clang    x86_64-linux-android28-clang++
>
> Gotta pick one of the available options.

i actually meant that you'd want something like

    `dirname $0`/clang --target=x86_64-linux-android10000 "$@"

> > pro: you'll never have to update your
> > instructions. con: if we ship an NDK with new headers but forget to
> > update libc.a, you'll likely be the first to catch that.
>
> What would be really really nice is if you had -cc and -c++ symlinks to the
> latest -clang and -clang++ versions in the zip file. Then I wouldn't have to
> create them, so I wouldn't have to work out which version is latest. (You could
> also have some kind of "latest" in there, but... the -cc and -c++ symlinks _are_
> a "latest" in directly usable format...)
>
> [puppy eyes intensify]
>
> >> Rob
> >
>
> Rob