In the Android NDK, clang is located in an entirely different directory from the GCC-based toolchain that we use. This would be fine, except that useful build tools (strip, ar, etc.) are also located in the GCC directory, and we basically assume for cross compiles that wherever the compiler is, there are the tools also. To properly support clang on Android, we need to remove this assumption somehow. Or we could just use the NDK's make-ndk-sysroot.sh script (or whatever it's called) and eliminate a lot of headaches.

The NDK's clang binaries are also not ${TARGET}-prefixed, so we may need to be careful about not using the NDK's clang for host binaries... (although last time I looked, the search list for the NDK's clang included the host directories, so perhaps that was done so you don't have to make a careful distinction between the host and target...?)

Did you actually try to build with clang and fail? Because the current way things work should allow what you want: set CC to the full path of clang, and set the toolchain prefix to its current value. (also note we're not assuming anything about locations. The real right thing would be for PATH to contain the right directories, and the toolchain prefix not to contain a path ; but things should still work without adjusting PATH, see above)

(In reply to Mike Hommey [:glandium] from comment #2) > Did you actually try to build with clang and fail? Because the current way > things work should allow what you want: set CC to the full path of clang, > and set the toolchain prefix to its current value. I haven't tried to do that, although that would work as a stopgap. I was thinking that we'd want a configure options --with-android-llvm-toolchain version...although given that the NDK doesn't currently include multiple LLVM versions, and GCC will eventually be removed, perhaps we can just set CC for now and eventually just default to using LLVM always?

Building with clang has indicated that we don't need to worry about this.