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

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

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

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

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

janvorli

LGTM, thank you!

janvorli · 2025-01-15T11:23:03Z

@filipnavara can you please resolve the conflicts so that we can merge the change in?

filipnavara · 2025-01-15T11:37:27Z

@filipnavara can you please resolve the conflicts so that we can merge the change in?

Done.

janvorli · 2025-01-15T16:13:48Z

@filipnavara there are some test failures, I think that I've seen some of them in the previous runs already. Could you please take a look to see if they could possibly be related to this change?

filipnavara · 2025-01-15T16:26:39Z

The tvOS failures seems to be [Apple-mobile] System.Tests.StringTests.[Starts,Ends]WithNoMatch_StringComparison test failure #108832 / [Apple][x64] EndsWithNoMatch_StringComparison test failure #108747. The issue is closed but without any link to a resolution. The failure is happening with MonoVM and not in any code that this PR touched.
wasi-wasm is infrastructure issue.
osx-arm64 failed with The process cannot access the file '/Users/runner/work/1/s/artifacts/bin/Microsoft.NETCore.App.MonoCrossAOT/Release/net10.0/osx-arm64/Microsoft.NETCore.App.MonoCrossAOT.deps.json' because it is being used by another process.. I think it would succeed on a re-run. I don't see an open issue for this.
windows-x64 failed with Could not read lines from file "D:\a\_work\1\s\artifacts\obj\Microsoft.NETCore.App.MonoCrossAOT\Release\net10.0\win-x64\Microsoft.NETCore.App.MonoCrossAOT.sfxproj.FileListAbsolute.txt". The process cannot access the file 'D:\a\_work\1\s\artifacts\obj\Microsoft.NETCore.App.MonoCrossAOT\Release\net10.0\win-x64\Microsoft.NETCore.App.MonoCrossAOT.sfxproj.FileListAbsolute.txt' because it is being used by another process.. Seems similar enough to the above?

I don't think any of that is related to this PR but it may be worth re-running the affected pipelines.

filipnavara · 2025-01-15T22:55:32Z

Issue was filed for the MonoCrossAOT build errors - #111474. It happened in an unrelated PR.

jkotas · 2025-01-18T23:07:04Z

@filipnavara Could you please resolve the conflict?

filipnavara · 2025-01-18T23:21:05Z

@filipnavara Could you please resolve the conflict?

Done

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

filipnavara and others added 10 commits January 7, 2025 11:25

Fix rpath on MacCatalyst

c9fcfc8

Apply suggestions from code review

9bfff93

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

Use CORECLR_HOSTING_API_LINKAGE for extern 'C'

c15e10b

Remove extra #include

cdd6053

Drop ICU linkage (not needed with Hybrid Globalization)

d3f89f8

Move jit_write_protect_np initialization

bf2a68a

Use __APPLE__ in PAL instead of TARGET_APPLE for consistency

5f50b02

Revert changes to native libs and exclude singlefilehost

7790c37

Revert more singlefilehost changes

e24f874

Remove excessive -D_XOPEN_SOURCE

ec579a6

filipnavara force-pushed the coreclr-ioslike-2 branch from 0eae3aa to ec579a6 Compare January 7, 2025 10:25

Fix build with FEATURE_PERFTRACING_STANDALONE_PAL (debug libs)

24499be

janvorli approved these changes Jan 7, 2025

View reviewed changes

build-analysis bot mentioned this pull request Jan 7, 2025

SIGKILL (OOM?) while running LibraryImportGenerator.Tests w/o actionable log messages or artifacts dotnet/dnceng#2496

Open

3 tasks

filipnavara added 2 commits January 15, 2025 12:32

Build with FEATURE_STANDALONE_GC (pending a build fix for debug libs)

1094de7

Merge remote-tracking branch 'dotnet/main' into coreclr-ioslike-2

338030a

This was referenced Jan 15, 2025

slow macOS - "##[error]The job running on agent Azure Pipelines 9 ran longer than the maximum time of 60 minutes." dotnet/dnceng#1883

Open

System.Runtime.Tests.WorkItemExecution "crash" on tvOS #106319

Open

This was referenced Jan 17, 2025

Beginnings of native Android build #110471

Open

Resolve TCP/IP EventPipe support on CoreCLR Android #111524

Open

Merge branch 'main' into coreclr-ioslike-2

3f25790

build-analysis bot mentioned this pull request Jan 19, 2025

MSBuild crashing in the build #92290

Open

Merge remote-tracking branch 'dotnet/main' into coreclr-ioslike-2

13eb081

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 left a comment

janvorli commented Jan 15, 2025

filipnavara commented Jan 15, 2025

janvorli commented Jan 15, 2025

filipnavara commented Jan 15, 2025 •

edited

Loading

filipnavara commented Jan 15, 2025

jkotas commented Jan 18, 2025

filipnavara commented Jan 18, 2025

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

janvorli left a comment

Choose a reason for hiding this comment

janvorli commented Jan 15, 2025

filipnavara commented Jan 15, 2025

janvorli commented Jan 15, 2025

filipnavara commented Jan 15, 2025 • edited Loading

filipnavara commented Jan 15, 2025

jkotas commented Jan 18, 2025

filipnavara commented Jan 18, 2025

filipnavara commented Jan 15, 2025 •

edited

Loading