NativeAOT library mode on iOS-like platforms

[filipnavara]

As documented in royalapplications/beyondnet#34 (comment) there's a demand to get NativeAOT library mode working on iOS-like platforms. This is specifically for net8.0 TFM and NOT the Xamarin net8.0-ios TFM which may run into similar issues but requires fixes in the Xamarin SDK. It currently requires a couple of workaround and we should look into fixing the underlying issues:

• Linking step doesn't use correct -sysroot/-target. We currently bundle the apps through AppleAppBuilder in dotnet/runtime, and a custom bundler in Xamarin. However, for dylib builds the NativeAOT linker step on its own is mostly sufficient. We just need to specify proper -target (eg. apple-arm64-ios11.0 or similar) and sysroot. The sysroot can be obtained through xcrun, or we can simply execute the whole linker using xcrun -sdk iphoneos clang <options> command to achieve the same result.
• There's a conflict with the new mobile-librarybuilder-experimental workload which currently needs to be disabled with _IsAppleMobileLibraryMode=false. We should disable it automatically for NativeAOT publishing.

[ghost]

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

Issue Details

---

As documented in royalapplications/beyondnet#34 (comment) there's a demand to get NativeAOT library mode working on iOS-like platforms. This is specifically for net8.0 TFM and NOT the Xamarin net8.0-ios TFM which may run into similar issues but requires fixes in the Xamarin SDK. It currently requires a couple of workaround and we should look into fixing the underlying issues:

• Linking step doesn't use correct -sysroot/-target. We currently bundle the apps through AppleAppBuilder in dotnet/runtime, and a custom bundler in Xamarin. However, for dylib builds the NativeAOT linker step on its own is mostly sufficient. We just need to specify proper -target (eg. apple-arm64-ios11.0 or similar) and sysroot. The sysroot can be obtained through xcrun, or we can simply execute the whole linker using xcrun -sdk iphoneos clang <options> command to achieve the same result.
• There's a conflict with the new mobile-librarybuilder-experimental workload which currently needs to be disabled with _IsAppleMobileLibraryMode=false. We should disable it automatically for NativeAOT publishing.

Author:	filipnavara
Assignees:	-
Labels:	untriaged, area-NativeAOT-coreclr
Milestone:	-

[akoeplinger]

/cc @steveisok

[ghost]

Tagging subscribers to 'os-ios': @steveisok, @akoeplinger, @kotlarmilos
See info in area-owners.md if you want to be subscribed.

Issue Details

---

As documented in royalapplications/beyondnet#34 (comment) there's a demand to get NativeAOT library mode working on iOS-like platforms. This is specifically for net8.0 TFM and NOT the Xamarin net8.0-ios TFM which may run into similar issues but requires fixes in the Xamarin SDK. It currently requires a couple of workaround and we should look into fixing the underlying issues:

• Linking step doesn't use correct -sysroot/-target. We currently bundle the apps through AppleAppBuilder in dotnet/runtime, and a custom bundler in Xamarin. However, for dylib builds the NativeAOT linker step on its own is mostly sufficient. We just need to specify proper -target (eg. apple-arm64-ios11.0 or similar) and sysroot. The sysroot can be obtained through xcrun, or we can simply execute the whole linker using xcrun -sdk iphoneos clang <options> command to achieve the same result.
• There's a conflict with the new mobile-librarybuilder-experimental workload which currently needs to be disabled with _IsAppleMobileLibraryMode=false. We should disable it automatically for NativeAOT publishing.

Author:	filipnavara
Assignees:	-
Labels:	untriaged, os-ios, area-NativeAOT-coreclr
Milestone:	8.0.0

[ivanpovazan]

/cc: @curia-damiano you might be interested

[shana]

+10 for not having to hardcode the sysroot path to get this to work. Everything else in the build system seems to be working great (as seen in godotengine/godot#82729), this is the only stumbling block that's making it slightly awkward.

[shana]

@MichalStrehovsky BTW, looks like the workaround mentioned in #91997 is only for the -lc++ linker argument, and not for the -isysroot path, so there's no current (easy) workarounds for this. I'm doing xcode location detection with a target running xcode-select right now, so it's not too horrible :)