Arcade AOT compiler configuration breaks ilcompiler fallback logic
- Dominant language
- C#
- Stars
- 729
- Forks
- 397
- Avg merge
- 3d 15m
- Merged PRs (30d)
- 149
Description
The SDK is now building an AOT component in .NET 11. In GH codespaces, it was using the default ilcompiler experience which tries to find clang first and then falls back to gcc:
https://github.com/dotnet/runtime/blob/main/src/coreclr/nativeaot/BuildIntegration/Microsoft.NETCore.Native.Unix.targets#L18
A recent change to arcade broke this:
https://github.com/dotnet/dotnet/pull/6802
The intent of the change was to simplify logic that some repos had for picking their native compiler. However, by setting CppCompilerAndLinker to clang, the ilcompiler never falls back to gcc.
The SDK team has a workaround here of just installing clang:
https://github.com/dotnet/sdk/pull/55291
Should the arcade logic try to detect that clang is not present and fallback to gcc? Should runtime allow you to specify a fallback (it clears that property today)?
CC @sbomer @am11 @akoeplinger who may know more about the intent of the arcade change that broke this and may be able to propose where the fix should live.
Contributor guide
Research direction
Start with src/coreclr/nativeaot/BuildIntegration/Microsoft.NETCore.Native.Unix.targets and compare the compiler-setting change in dotnet/dotnet#6802 with the workaround in dotnet/sdk#55291. Reproduce the behavior in a GitHub Codespace, then establish whether Arcade or Runtime should own the fallback so clang absence still permits gcc.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- build-system, tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100