Fix official builds

[MichalStrehovsky]

@am11 I have to revert these again, sorry. Out of 5 last official build attempts, 4 failed in the native AOT MUSL x64 or arm64 legs with the

cdac-build-tool -> /__w/1/s/artifacts/bin/coreclr/linux.x64.Release/cdac-build-tool/cdac-build-tool.dll
  Generating native code
  /tmp/MSBuildTempcloudtest_azpcontainer/tmp53d7bd47a57a45a0a1b8ba82dd1868de.exec.cmd: line 2: \tools\ilc: command not found
/__w/1/s/.packages/microsoft.dotnet.ilcompiler/9.0.0-preview.6.24307.2/build/Microsoft.NETCore.Native.targets(310,5): error MSB3073: The command ""\tools\\ilc" @"/__w/1/s/artifacts/obj/cdacreader/Release/net9.0/linux-musl-x64/native/libcdacreader.ilc.rsp"" exited with code 127. [/__w/1/s/src/native/managed/cdacreader/src/cdacreader.csproj]
##[error].packages/microsoft.dotnet.ilcompiler/9.0.0-preview.6.24307.2/build/Microsoft.NETCore.Native.targets(310,5): error MSB3073: (NETCORE_ENGINEERING_TELEMETRY=Build) The command ""\tools\\ilc" @"/__w/1/s/artifacts/obj/cdacreader/Release/net9.0/linux-musl-x64/native/libcdacreader.ilc.rsp"" exited with code 127.

error that we've seen before. So it looks like it's still there, and still non-deterministic.

The command used is:

/__w/1/s/build.sh -ci -arch x64 -os linux -cross -s clr.nativeaotlibs+clr.nativeaotruntime+libs+packs -c Release /p:BuildNativeAOTRuntimePack=true /p:SkipLibrariesNativeRuntimePackages=true    /p:OfficialBuildId=20240626.1  

Or

/__w/1/s/build.sh -ci -arch arm64 -os linux -cross -s clr.nativeaotlibs+clr.nativeaotruntime+libs+packs -c Release /p:BuildNativeAOTRuntimePack=true /p:SkipLibrariesNativeRuntimePackages=true    /p:OfficialBuildId=20240626.5  

I was digging in the binlogs (I don't think I can share them externally because it's from the official build machine and I don't know if there are secrets) and the problem seems to be:

Bad:

Good:

The cdacreader project is hooked up in a bit of an odd way so maybe it doesn't restore the host ILCompiler runtime pack and we just have a happy accident that something else does restore it before sometimes.

Looks like cdacreader was excluded from building on MUSL before this change and now we've centralized it and it's no longer excluded and we're running into this? Cc @lambdageek @jkoritzinsky

[am11]

@MichalStrehovsky i don't think non-portable build should block us in the first place. Just disable it for non-portable build as before rather than the revert?

[MichalStrehovsky]

@MichalStrehovsky i don't think non-portable build should block us in the first place. Just disable it for non-portable build as before rather than the revert?

You mean the source build issue in the SDK repo (dotnet/sdk#41793)? That one is separate.

We're having issues getting official builds of the dotnet/runtime repo out because there's an apparent race condition.

[am11]

In the original PR, I didn't touched cdacreader until I was asked. I think reverting src/native/managed/compile-native.proj should be enough for both problems.

[MichalStrehovsky]

In the original PR, I didn't touched cdacreader until I was asked. I think reverting src/native/managed/compile-native.proj should be enough for both problems.

If you can make a PR, I can approve and merge and we'll see. (If I make a PR, we need to find someone else who can approve before we can merge and it's late night in the US).

[MichalStrehovsky]

Closing in favor of #104072. I expect that one will sweep the MUSL issue back under the rug for someone else to discover again later (we need to fix the official build).