[clr-ios] Update build system to produce artifacts for dynamic linking on Apple mobile

[kotlarmilos]

Description

Enable building the .NET runtime for dynamic linking on Apple mobile platforms (iOS, tvOS, MacCatalyst). The build should produce a libcoreclr.dylib with the interpreter statically linked, ICU included in the app bundle, and full support for both device and simulator builds.

Tasks:

• [clr-ios] Guard code-versioning paths with FEATURE_CODE_VERSIONING #120812
• [ios-clr] Update Subsets.props to build CoreCLR subset for Apple mobile #120787
• Update the build system to statically link the interpreter into libcoreclr.dylib
• Rename or remove Mono/iOS-simulator–specific functions
• Include the ICU library and data files in the app bundle
• Fix handling of async Task<int> Main to correctly propagate the exit code
• Fix retrieval of pinvoke methods in the sample app
• Add build and runtime support for tvOS and tvOS simulator
• Test builds for x64 simulator architectures
• [clr-ios] Update build system to produce artifacts for dynamic linking on Apple mobile #119006

[jkotas]

the static library path (InitializeStaticJIT) or the dynamic library path (LoadAndInitializeJIT) through hard-coded macros

Is this about the JIT (libclrjit.dylib) or about the whole runtime (libcoreclr.dylib)?

I agree that we want to option to have runtime in a dynamic library (libcoreclr.dylib) that just gets copied over for F5 scenarios and for our own internal testing.

I do not see the value of providing app-configurable options for having dynamically linked JIT vs. statically linked JIT. What would be the scenario for that?

[kotlarmilos]

Sorry, I wasn’t explicit about the components. I was thinking about the compiler (both JIT and interpreter) and runtime.

The main considerations are extensibility and performance. On simulators and MacCatalyst, JIT is allowed. With dynamic linking, we could statically link the JIT while loading the interpreter dynamically. This would require shipping both dynamic and static libraries: the runtime and interpreter for devices; the runtime, interpreter, and JIT for simulators. The linking mode would then be selected at app build time. To support this, the current approach in codeman.cpp for loading the compiler would need to change. Instead of hard-coded macros for Apple mobile, we would use an app-build property. WASM would remain restricted to static linking only.

On the performance side, I’m also wondering whether dynamically linking the interpreter (and possibly other components) could reduce build times in Debug configurations.

[jkotas]

I’m also wondering whether dynamically linking the interpreter (and possibly other components) could reduce build times in Debug configurations.

Right, we want to have dynamic libraries (libcoreclr.dylib, etc.) for debug app configuration, and static linking of everything for release app configuration.

I do not think we need to have different linking of the JIT between these two configurations. The JIT can be statically linked in both cases (statically linked into libcoreclr.dylib for F5, and into the app itself for release). I agree that dynamic linking of the JIT would work for F5 too, but I do not see why it is required. It would make the file layout more similar to non-device OSes Windows/Linux/macOS and we can do it for that as nice-to-have.

[kotlarmilos]

Ok, thanks. It makes sense to statically link the compiler into libcoreclr.dylib for Debug builds and into the app bundle for Release builds. In that case, LoadAndInitializeJIT won’t be used on devices. I’ll update the description and use this as the tracking issue.