[NativeAOT] Passing Full Path to CppCompilerAndLinker Errors

[CasualPokePlayer]

Description

For NativeAOT Unix targets, CppCompilerAndLinker is a property which may be set in order to use a custom compiler/linker.

For Android NativeAOT development, I have found it potentially useful to pass a full path to the compiler, based on an ANDROID_NDK_ROOT environment variable. This allows me to avoid permanently setting my PATH to NDK's clang location (as it would interfere with a separate clang installation), and allow me to automate the process of setting the correct cross compiling setup from within the .csproj.

However, passing a full path to CppCompilerAndLinker will result in an error. This is due to the checks verifying CppCompilerAndLinker is in PATH, as the underlying where /Q not liking a full path and proceeding to error.

I haven't tested what happens on other platforms (which use command -v instead), they might work or might not work.

Reproduction Steps

1. Create a sample NativeAOT project.
2. Publish under a Unix RID with CppCompilerAndLinker set to an absolute path to e.g. clang.
3. Error

The general setup NativeAOT on Android would cover the general use case on Windows here: https://github.com/dotnet/runtime/blob/main/src/coreclr/nativeaot/docs/android-bionic.md

Expected behavior

The compiler should be accepted and used without error.

Actual behavior

Error

Regression?

No response

Known Workarounds

Running a shell script relative to the .csproj which just executes the full path to the compiler would work. This is notably done in the example NativeAOT Android project with JNI: https://github.com/josephmoresena/NativeAOT-AndroidHelloJniLib

Configuration

• .NET 8
• Windows 10
• x64
• As stated, I have not tested other operating systems which use a different way to check if the compiler is present.

Other information

No response

[dotnet-policy-service[bot]]

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas See info in area-owners.md if you want to be subscribed.

[MichalStrehovsky]

Clang is not the only tool we need to invoke. We also need objcopy/strip. Assuming them on path makes things easier quite a bit easier.

[CasualPokePlayer]

That's fine, there are other properties (ObjCopyName) that could be set by the user for those (which also have PATH checks, which would fail too)

(edit: sorry for issue close, accidental finger slip)

[CasualPokePlayer]

I haven't tested what happens on other platforms (which use command -v instead), they might work or might not work.

Testing this and it appears to work just fine (testing on Ubuntu 22.04 on WSL2). So this just appears to be a (host) Windows specific issue (which I suppose bionic is the main use case since that implicitly has to be cross compiled).