Add support for building CoreCLR for MacCatalyst/iOS simulator #109928

filipnavara · 2024-11-18T15:29:35Z

Re-open and rebase of #98127

Build instructions:

Build the runtime pack and tools: ./build.sh clr+clr.runtime+libs+packs -os [iossimulator/maccatalyst] -arch [x64/arm64] -cross -c Release
Run the sample app: ./dotnet.sh publish src/mono/sample/iOS/Program.csproj -c Release /p:TargetOS=maccatalyst /p:TargetArchitecture=arm64 /p:DeployAndRun=true /p:UseMonoRuntime=false /p:RunAOTCompilation=false /p:MonoForceInterpreter=false

Related work:

Counter-part Xamarin changes needed to build full workload and run MAUI apps: [net10.0] Enable CoreCLR for all platforms. xamarin/xamarin-macios#21627 / https://github.com/xamarin/xamarin-macios/compare/net8.0...filipnavara:xamarin-macios:net8.0-coreclr-ioslike?expand=1
SDK would need to be updated with RIDs in KnownRuntimeFramework to use this
tvOS support is dropped in this version of the PR. The OS doesn't expose Mach exceptions and it would need larger modification in the runtime to add the support.
We don't use the new JIT API (Investigate use of new Apple JIT APIs #108423). That's orthogonal problem but would be a necessity to support MacCatalyst/arm64 in production.

Notably, this doesn't include CI scripts to build this or the runtime packs. I am open to suggestions on how to better split this into more digestible/reviewable chunks.

src/coreclr/hosts/inc/coreclrhost.h

src/coreclr/pal/src/CMakeLists.txt

AaronRobinsonMSFT · 2024-11-18T16:15:26Z

src/coreclr/pal/src/include/pal/dbgmsg.h

@@ -494,7 +494,7 @@ if new_level is -1, the nesting level will not be modified
 --*/
 int DBG_change_entrylevel(int new_level);

-#ifdef __APPLE__
+#ifdef TARGET_OSX


Is TARGET_OSX a subset of TARGET_APPLE?

Yes, it is.

src/coreclr/pal/src/map/virtual.cpp

src/native/corehost/hostpolicy/hostpolicy_context.cpp

src/native/libs/System.Native/entrypoints.c

src/native/libs/System.Security.Cryptography.Native.Apple/entrypoints.c

janvorli · 2024-11-19T00:09:04Z

src/coreclr/dlls/mscoree/coreclr/CMakeLists.txt

@@ -228,6 +228,9 @@ endif(CLR_CMAKE_TARGET_WIN32)

 # add the install targets
 install_clr(TARGETS coreclr DESTINATIONS . sharedFramework COMPONENT runtime)
+if(CLR_CMAKE_HOST_MACCATALYST OR CLR_CMAKE_HOST_IOS)
+    install_clr(TARGETS coreclr_static DESTINATIONS . sharedFramework COMPONENT runtime)


Why do we need to install this?

iOS generally restricts linking to static libraries or dynamic frameworks distributed with the app itself. The aim was to include statically built CoreCLR in the runtime pack.

I wonder if that means that the single file is the only deployment mechanism on iOS. If it is the case, then I am not sure what would be the scenario where developers would explicitly use the static version of coreclr.

Linking with a static library typically results in smaller apps, which is why we've always linked Mono statically by default.

Linking dynamically can make the build a little bit faster (from past experience in Xamarin, we never ported this to .NET when we migrated due to time constraints).

The single file is a host statically linked to all the native libraries including coreclr. The scenario when the developers would need static coreclr library would be when they want to use their own host. Thinking about it more, I guess distributing the static coreclr version actually makes sense to enable such scenarios.

Yes, that sounds like what we want.

Note that .dylib won't do (Apple doesn't allow them in iOS apps), each dynamic library has to be made into a .framework (which works).

FWIW Apple has recommended using no more than 6-8 .frameworks because otherwise it affects startup performance.

src/coreclr/hosts/inc/coreclrhost.h

janvorli · 2024-11-19T00:26:08Z

src/coreclr/pal/src/exception/seh-unwind.cpp

@@ -44,7 +44,7 @@ Module Name:

 #endif // HOST_UNIX

-#if defined(TARGET_OSX) && defined(HOST_ARM64) && !defined(HAVE_UNW_AARCH64_X19)
+#if defined(TARGET_APPLE) && defined(HOST_ARM64) && !defined(HAVE_UNW_AARCH64_X19)


There are over 100 usages of __APPLE__ define to identify apple stuff in the PAL. I would prefer staying consistent with that (or change all the usages of the __APPLE__ to TARGET_APPLE)

Fair enough, there's at least 147 usages of __APPLE__ in CoreCLR vs. 71 of TARGET_APPLE (in this PR). I can unify it on __APPLE__ if that's preferred.

Yes, keeping uniformity is preferred. In some later PR, we can later change everything to TARGET_APPLE, but doing it now would unnecessarily grow the already large number of files changed in this PR and do that in places that are unrelated to the gist of this PR.

Makes sense. I'll update it.

(may take me a day or two to get to it; currently on sick leave)

src/coreclr/pal/src/map/virtual.cpp

src/coreclr/pal/src/misc/dbgmsg.cpp

src/native/corehost/apphost/static/CMakeLists.txt

src/native/libs/System.Globalization.Native/CMakeLists.txt

janvorli · 2024-11-19T01:00:26Z

src/native/libs/System.Native/entrypoints.c

@@ -34,6 +34,7 @@
 static const Entry s_sysNative[] =
 {
    DllImportEntry(SystemNative_FStat)
+#if !defined(TARGET_APPLE) || defined(TARGET_OSX)


It seems that we tend to keep this list the same for all platforms and rather handle the missing functionality in the actual implementation of the methods. E.g. for WASI, many of the methods return EINVAL or NULL.

This is preexisting implementation where it was not done that way. We just never compiled the entrypoints.c on mobile platforms.

Since this is used for corehost which is not particularly useful on mobile platforms maybe I can just drop this part of change and try to exclude corehost build.

Done. There are some additional changes I can revert once #110092 and #110023 gets in.

Rebased after #110092 merge now.

…ld.sh clr+clr.nativeaotlibs+libs+packs -os [iossimulator/maccatalyst/ios] -arch arm64 -cross' Build the singlefilehost even if we don't currently use it Make coreclrhost.h compatible v C(not++) Fix TargetOS::IsMacOS WIP: AppleAppBuilder support for CoreCLR Make the sample app working: dotnet publish src/mono/sample/iOS/Program.csproj -c Release /p:TargetOS=iossimulator /p:TargetArchitecture=arm64 /p:AppleAppBuilderRuntime=CoreCLR /p:DeployAndRun=true /p:UseMonoRuntime=false /p:RunAOTCompilation=false /p:MonoForceInterpreter=false Cleanup Update src/tasks/AppleAppBuilder/AppleAppBuilder.csproj Co-authored-by: Adeel Mujahid <3840695+am11@users.noreply.github.com> Use sys_icache_invalidate for all iOS-like platforms Consolidate macOS-only entrypoints in a single #if block Apply feedback Fix jitinterface cross-build Infer AppleAppBuilderRuntime from UseMonoRuntime and UseNativeAOTRuntime Minor changes to test infrastructure Add basic documentation Add nearly complete support for building runtime tests Fix building seh-unwind with older iOS SDK Use enum for TargetRuntime in AppleAppBuilder Fix LibraryBuilder build Cleanup Fix after rebase Revert accidental change Fix tvOS build Drop CoreCLR tvOS Simulator support for now

Co-authored-by: Aaron Robinson <arobins@microsoft.com>

filipnavara requested review from janvorli, AaronRobinsonMSFT, a team, steveisok and vitek-karas as code owners November 18, 2024 15:29

dotnet-issue-labeler bot added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Nov 18, 2024

dotnet-policy-service bot added the community-contribution Indicates that the PR has been added by a community member label Nov 18, 2024

AaronRobinsonMSFT reviewed Nov 18, 2024

View reviewed changes

tommcdon requested review from thaystg and mikem8361 November 18, 2024 16:46

jkotas added area-Infrastructure-coreclr and removed needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners labels Nov 18, 2024

matouskozak added os-ios Apple iOS os-maccatalyst MacCatalyst OS and removed os-ios Apple iOS labels Nov 18, 2024

janvorli reviewed Nov 19, 2024

View reviewed changes

This was referenced Nov 19, 2024

chrome-DebuggerTests.GetPropertiesTests timing out #109070

Open

[MT][Firefox] Wasm test failure: System.IO.FileNotFoundException : Could not load file or assembly xunit.assert #109945

Open

filipnavara mentioned this pull request Nov 22, 2024

Remove usage of HP libunwind on Apple platforms #110023

Closed

build-analysis bot mentioned this pull request Nov 29, 2024

Error reported in diagnostic logs. Please examine the log for more details dotnet/dnceng#1928

Open

3 tasks

This was referenced Nov 29, 2024

The Operation will be canceled. The next steps may not contain expected logs. dotnet/dnceng#3008

Open

[wasm] Out of memory exception in System.Xml.XmlWriterApiTests.TCFullEndElement tests #110090

Open

filipnavara and others added 10 commits November 30, 2024 17:47

Fix rpath on MacCatalyst

7b5c2a3

Apply suggestions from code review

a918598

Co-authored-by: Aaron Robinson <arobins@microsoft.com>

Use CORECLR_HOSTING_API_LINKAGE for extern 'C'

078e390

Remove extra #include

eed2700

Drop ICU linkage (not needed with Hybrid Globalization)

7397eea

Move jit_write_protect_np initialization

5fe0ed4

Use __APPLE__ in PAL instead of TARGET_APPLE for consistency

44fe9c5

Revert changes to native libs and exclude singlefilehost

780667b

Revert more singlefilehost changes

5451afe

filipnavara force-pushed the coreclr-ioslike-2 branch from a746372 to 5451afe Compare November 30, 2024 16:47

Remove excessive -D_XOPEN_SOURCE

0eae3aa

This was referenced Nov 30, 2024

[browser][MT] MutexTests - operation does not support unaligned accesses #96191

Open

System.Formats.Nrbf.Tests timeouts #110285

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add support for building CoreCLR for MacCatalyst/iOS simulator #109928

Add support for building CoreCLR for MacCatalyst/iOS simulator #109928

filipnavara commented Nov 18, 2024

AaronRobinsonMSFT Nov 18, 2024

filipnavara Nov 18, 2024

janvorli Nov 19, 2024

filipnavara Nov 19, 2024

janvorli Nov 19, 2024

rolfbjarne Nov 19, 2024

janvorli Nov 19, 2024

rolfbjarne Nov 19, 2024

janvorli Nov 19, 2024

filipnavara Nov 20, 2024

janvorli Nov 20, 2024

filipnavara Nov 22, 2024

filipnavara Nov 30, 2024

janvorli Nov 19, 2024

filipnavara Nov 19, 2024

filipnavara Nov 30, 2024

filipnavara Nov 30, 2024

Add support for building CoreCLR for MacCatalyst/iOS simulator #109928

Are you sure you want to change the base?

Add support for building CoreCLR for MacCatalyst/iOS simulator #109928

Conversation

filipnavara commented Nov 18, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment