[Mobile] Implement CMake export module for CoreCLR on Android and Apple mobile

[kotlarmilos]

Description

Use CMake exports to generate a CMake module that the AppleAppBuilder and AndroidAppBuilder templates would consume (and as such would allow the runtime to control the complexity and the various templates just say "link against this target"). With that option, we'd limit the amount of knowledge that consuming repos would need to have.

[dotnet-policy-service]

Tagging subscribers to this area: @hoyosjs
See info in area-owners.md if you want to be subscribed.

[jkotas]

Does mobile user tooling have a dependency on cmake today? Would this introduce a new dependency that needs to get acquired somehow, etc.?

[jkoritzinsky]

Yes, both AndroidAppBuilder and AppleAppBuilder depend on CMake today to build the final app.

[grendello]

SDKs (Android, iOS and WASM), however, don't have dependency on cmake and it's unlikely they can take it (I'm thinking of application build time, not SDK build). In Android, we ship a minimal LLVM-based toolchain (in the context of static linking we have just the linker). It would be impossible for the SDKs to easily parse the cmake export statements. Instead, I would propose that the runtime build produces a file (e.g. JSON) that describes the following:

1. What static libraries have to be linked into the final application and in which order. This must allow for duplicate entries (since linker processes inputs in-order, sometimes it is necessary to mention a library twice if there are e.g. circular dependencies)
2. What required flags are to be passed to the linker. We currently have 3 linkers in use across the SDKs, the file would need to take each of them into account
3. Optional components (not used right now, but might be in the future - something a'la Mono components)

All that information is available for the CoreCLR build, so it shouldn't be a problem generating such a file. With the above information, the entire application linking process on the SDK side would be quite painless. And with the 1. above requiring a list of libraries, the runtime would have flexibility in how it distributes its components.

/cc @rolfbjarne @lewing @steveisok

[rolfbjarne]

1. I've never seen any ordering issues on macOS (and other Apple platforms), so that is hopefully a non-issue. As for selecting which object files to link with: if there are no duplicate symbols across all object files, and all required symbols can be seen by the native linker (i.e. no dynamic linking / dlopen / dlsym) then we can just link with all of them, and the native linker will pick the object files it needs.

2. At least for Mach-O files, it's possible to add any linker flags inside .o files using the LC_LINKER_OPTION load command:

   • https://www.smileykeith.com/2022/02/23/lc-linker-option/
   • https://milen.me/writings/auto-linking-on-ios-and-macos/

   This would avoid the whole problem of passing required linker flags elsewhere.

3. If there are duplicate symbols across object files, this might be solved with something like Mono's components.