.NET 6: LLVM AOT doesn't work on MacCatalyst

[akoeplinger]

Ported from dotnet/runtime#57589 by @filipnavara

Description

Example application (create from empty project with modified .csproj):
Archive.zip

Configuration

.NET 6.0.100-rc.1.21415.3
macOS 12.0 Beta
Xcode 13 beta 4 (iirc)

Regression?

It probably never worked?

Other information

  ld: building for Mac Catalyst, but linking in object file built for , file '/Users/filipnavara/Projects/llvmbug/obj/Debug/net6.0-maccatalyst/maccatalyst-arm64/nativelibraries/aot-output/arm64/llvmbug.dll.llvm.o'
  clang: error: linker command failed with exit code 1 (use -v to see invocation)
  
/usr/local/share/dotnet/packs/Microsoft.MacCatalyst.Sdk/15.0.100-preview.7.230/targets/Xamarin.Shared.Sdk.targets(847,3): error : clang++ exited with code 1 [/Users/filipnavara/Projects/llvmbug/llvmbug.csproj]
/usr/local/share/dotnet/packs/Microsoft.MacCatalyst.Sdk/15.0.100-preview.7.230/targets/Xamarin.Shared.Sdk.targets(847,3): error :          [/Users/filipnavara/Projects/llvmbug/llvmbug.csproj]

Looks like the LLVM compiler didn't get passed the -target arm64-apple-ios14.2-macabi. Note that other targets use -mtriple=... which doesn't work on MacCatalyst AFAIK.

[filipnavara]

Thanks, I was just about to repost it but you beat me by a minute :)

[filipnavara]

Ref: dotnet/runtime#57687

[AraHaan]

I seem to now be hitting this issue with Microsoft.MacCatalyst.Sdk version 15.0.100-rc.2.682.

This is when I try to make an MacOS application targeting both x64 and arm64.

[rolfbjarne]

@AraHaan please file a new issue, whatever is happening is not the same issue as this one.

[AraHaan]

I found out the issue was that it seems to not like the usage of HttpClient when I have it in a constructor parameter that basically the instance gets passed to it from DependencyInjection and so it blows up at the AOT step.

[rolfbjarne]

@AraHaan

I found out the issue was that it seems to not like the usage of HttpClient when I have it in a constructor parameter that basically the instance gets passed to it from DependencyInjection and so it blows up at the AOT step.

That sounds like something worthy of a bug report, so we can look into it and maybe fix it.