[FR] improve fallback behavior of ndk-which when triple-prefixed tools are not found

[Hsilgos]

Description

Currently we switch from 21.4.7075529 to 23.0.7599858 and found an issue.
In our build script we use ndk-which utility to find readelf.
In NDK 23 it stopped to show any result.

Step to reproduce:
Run ~/AndroidSDK/ndk/23.0.7599858/ndk-which --abi x86_64 readelf
Expected result: Full path to readelf utility.
Actual result: empty output.

Details:
After small debugging it's clear that ndk-which is trying path ~/AndroidSDK/ndk/23.0.7599858/toolchains/llvm/prebuilt/darwin-x86_64/bin/x86_64-linux-android-readelf which doesn't exist in NDK anymore.
Either this binary should be returned back or ndk-which must try path ~/AndroidSDK/ndk/23.0.7599858/toolchains/llvm/prebuilt/darwin-x86_64/bin/llvm-readelf instead.

Environment Details

• NDK Version: 23.0.7599858
• Host OS: Mac (may be other OSes)
• ABI: Any

[enh-google]

yeah, the GNU binutils have been removed in r23. you'll want to use llvm-readelf instead. (no need to choose a different binary for each architecture --- one benefit of the LLVM tools is that they "just work" regardless of architecture.)

so this is working as intended from that perspective, but... this makes me realize that when the release notes say "GNU binutils ... has been removed", it's not necessarily the case that everyone knows what GNU binutils is. maybe we should call out the individual tools explicitly in the changelog, and list the replacement next to each one? (for anyone reading this before we do that --- just remove any existing architecture specific prefix like x86_64-linux-android- and replace it with llvm- instead.)

[Hsilgos]

yeah, the GNU binutils have been removed in r23. you'll want to use llvm-readelf instead. (no need to choose a different binary for each architecture --- one benefit of the LLVM tools is that they "just work" regardless of architecture.)

so this is working as intended from that perspective, but... this makes me realize that when the release notes say "GNU binutils ... has been removed", it's not necessarily the case that everyone knows what GNU binutils is. maybe we should call out the individual tools explicitly in the changelog, and list the replacement next to each one? (for anyone reading this before we do that --- just remove any existing architecture specific prefix like x86_64-linux-android- and replace it with llvm- instead.)

I see your point. But to my understanding ndk-which is more than tool which combines ABI + architecture + platform + utility-name, but it's more or less cross platform entry point to find necessary tool in NDK's directory hierarchy. All I need is environment variable ANDROID_NDK_HOME and that's it, I was able to find necessary tool like readelf on any platform with simple call to ndk-which. It's convenient and would be nice to have.

[enh-google]

yeah, we actually talked about this in yesterday's team meeting and @DanAlbert suggested that what we should probably do is change it so that if ndk-which foo fails, it tries to look for llvm-foo too as an automatic fallback. there are a few special cases where there's a tool that isn't equivalent, but we should probably catch those too and output an error message telling you what your choices are.

[DanAlbert]

(we generally don't backport features but the work is so non-invasive I think it makes sense to backport once done)

[DanAlbert]

Should be fixed in r23 build 8486889.