osx-arm64 SDK 11.0.100-preview.5.26263.103 ships dSYM in place of libdotnet-aot.dylib

[steveisok]

Describe the bug

The osx-arm64 tarball for SDK 11.0.100-preview.5.26263.103 places a Mach-O dSYM companion file at <sdk>/libdotnet-aot.dylib instead of the actual NativeAOT shared library. Any dotnet invocation that hits the muxer's new AOT fast path (added in dotnet/runtime#126596, packaged via #54056) prints a dlopen error to stderr because dyld rejects the dSYM with unloadable mach-o file type 10.

This breaks downstream consumers of the preview SDK on macOS arm64 — for example, building debuggee projects in dotnet/diagnostics fails with MSBuild MSB3073 ... exited with code -1.

To Reproduce

curl -sSL -o sdk.tar.gz \
  https://ci.dot.net/public/Sdk/11.0.100-preview.5.26263.103/dotnet-sdk-11.0.100-preview.5.26263.103-osx-arm64.tar.gz
mkdir extracted && tar -xzf sdk.tar.gz -C extracted ./sdk/11.0.100-preview.5.26263.103/libdotnet-aot.dylib
file extracted/sdk/11.0.100-preview.5.26263.103/libdotnet-aot.dylib

Expected behavior

The file at <sdk>/libdotnet-aot.dylib should be a Mach-O dylib (filetype MH_DYLIB = 6) exporting dotnet_execute, as described in dotnet/runtime#126171.

Actual behavior

extracted/sdk/11.0.100-preview.5.26263.103/libdotnet-aot.dylib: Mach-O 64-bit dSYM companion file arm64

Mach-O header (first 32 bytes):

00000000: cffa edfe 0c00 0001 0000 0000 0a00 0000
00000010: 0800 0000 f00c 0000 0000 0000 0000 0000

• Magic 0xFEEDFACF (Mach-O 64-bit, little-endian)
• filetype at offset 12 = 0x0000000A = MH_DSYM (10)

MH_DYLIB would be 0x00000006.

Symptom seen by consumers

EXEC : Failed to load /.../sdk/11.0.100-preview.5.26263.103/libdotnet-aot.dylib,
error dlopen(/.../libdotnet-aot.dylib, 0x0001): tried: '/.../libdotnet-aot.dylib'
(unloadable mach-o file type 10 '/.../libdotnet-aot.dylib'), ...

Verification

• SHA256 of the broken file inside the upstream tarball:
  08c6085e6c205875bbc9b876f765b3b7035c5d3226cf81fb07fb1bdea000e3b9
• SHA256 of the upstream tarball itself (ci.dot.net/public/Sdk/.../dotnet-sdk-11.0.100-preview.5.26263.103-osx-arm64.tar.gz):
  cd0fb25da6e377326c691967de13d607428709bb9c4b227484b2febadd0852f2
• Size: 10,928,757 bytes

The broken file matches byte-for-byte between a fresh upstream download and what dotnet-install.sh lays down locally, so this is a packaging issue, not extraction/codesign damage on the consumer side.

Likely cause

Looks like a packaging step in #54056 / the PublishDotnetAot target copied the dSYM companion produced by NativeAOT publish (and/or dsymutil) instead of the actual .dylib produced alongside it. Other Apple platforms (osx-x64, ios, maccatalyst) should be re-checked too — only osx-arm64 was verified here.

Workaround for consumers

Delete the file from the SDK after install — the muxer's try_invoke_aot_sdk returns false immediately when the file is absent and falls through to managed dotnet.dll:

rm <dotnet-root>/sdk/11.0.100-preview.5.26263.103/libdotnet-aot.dylib

Further technical details

• SDK: 11.0.100-preview.5.26263.103 (osx-arm64)
• Host: macOS 14+, Apple Silicon
• Relevant PRs:
  • Add logic to muxer to invoke AOT-ed SDK runtime#126596 — muxer loads dotnet-aot shared library from the resolved SDK dir
  • Add NativeAOT entry point for the dotnet CLI #54002 — NativeAOT entry point for dotnet CLI
  • Enable packaging of dotnet-aot #54056 — Enable packaging of dotnet-aot
  • Gate AOT fast path behind DOTNET_CLI_ENABLEAOT #54047 — Gate AOT fast path behind DOTNET_CLI_ENABLEAOT (gates the call, not the muxer dlopen)