[Toybox] NDK versions?

[Rob Landley]

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.

> 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