On 3/8/19 1:06 PM, enh wrote: > On Fri, Mar 8, 2019 at 10:47 AM Rob Landley <[email protected]> wrote: >> >> On 3/5/19 6:23 PM, Rob Landley wrote: >>> landley@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@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 _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
