std.Target.Query: fix compilation error

[dravenk]

closes #21668

[alexrp]

This isn't strictly related to this PR as it's just restoring existing behavior, but I don't understand why Android actually gets special-cased here. The idea seems to be that you can do CC=/path/to/android/sdk/cc zig libc -target arm-linux-androideabi or similar. But why is Android special in this regard? Surely I could just as well do CC=mips64-linux-gnuabi64-gcc zig libc -target mips64-linux-gnuabi64? cc @mikdusan

[mikdusan]

@alexrp I added this a while back leaning towards a curated approach of non-native libc detection and so checks were added for the only 2 platforms I tested against: various apple SDKs and android NDK. Also this impl doesn't explicitly allow NDK on macos or windows hosts, and although rare, the NDKs are available.

What I was happy about is that a garbage libc.txt was avoided. But if we take out canDetectLibC() (non-native logic), everything just falls through to LibCInstallation.findNative() and useless libc.txt is generated, or a very unhelpful error is given such as LibCRuntimeNotFound in case of zig libc -target aarch64-linux-android when NOT setting CC to the correct NDK pathname. We were getting issues raised against this.

In a better impl, what I'd like to see is some tech where an auto-generated libc.txt paths are fuzzy-validated.

To be clear, I think it is important to support exactly the use case pattern you listed (general cross compiler pathname) and it could very well be the curated approach is at odds with that goal.