Add workload for embeddable MonoVM

[marek-safar]

We'd like to add a new workload for everyone that could be used by developers to build libraries and apps which would like to use Mono embedding API to embed .NET runtime. The end goal is to allow developers to install all bits required to use embeddable .NET VM.

Work Items

• Build MonoVM runtime packs for all interesting targets (they should be shared with other workloads)
• Build EmbeddingMonoVM workload pack
  • Determine what kind of workload that should be
  • Determine if there is a need to split the static and dynamic aspect of libraries
• Create a custom tool which could be used by native build to (like simple pkg-config) get a reference to workload pack folder with C headers and native libs.

@lambdageek @steveisok @SamMonoRT

[ghost]

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

Issue Details

---

We'd like to add a new workload for everyone that could be used by developers to build libraries and apps which would like to use Mono embedding API to embed .NET runtime. The end goal is to allow developers to install all bits required to use embeddable .NET VM.

Work Items

• Build MonoVM runtime packs for all interesting targets (they should be shared with other workloads)
• Build EmbeddingMonoVM workload pack
  • Determine what kind of workload that should be
  • Determine if there is a need to split the static and dynamic aspect of libraries
• Create a custom tool which could be used by native build to (like simple pkg-config) get a reference to workload pack folder with C headers and native libs.

@lambdageek @steveisok @SamMonoRT

Author:	marek-safar
Assignees:	-
Labels:	area-AssemblyLoader-mono, untriaged
Milestone:	-

[CoffeeFlux]

Would my proposed header modernization for netcore go under this issue or a separate one?

[marek-safar]

That'd be a separate issue, this is primarily about building and packaging

[lambdageek]

I have an example of how we might do this today - https://github.com/lambdageek/monovm-embed-sample - it's not pretty. There are four steps:

1. Build and publish the managed code that will be invoked by the embedder. I use dotnet publish --self-contained for this step, with <TrimMode>copyused</TrimMode> to get a subset of the BCL.
2. Publish a fake managed project just to get nuget to download the runtime pack and hook onto the ResolveFrameworkReferences target to find where the native library and the embedding headers are located.
3. Use the info from step 2 to compile a native C/C++ project to embed the runtime. You also need to build a TRUSTED_PLATFORM_ASSEMBLY list in the C code based on the contents of Step 1.
4. To deploy, you copy the published managed code from Step 1, together with the native libraries from Step 2 and System.Private.CoreLib from Step 2 into the right place so that the native code from Step 3 can find them.

Step 1 is fine. Steps 2 and 3 should be streamlined. (Also note that in Step 2 right now there's no headers because of #46461). Step 4 needs to be simpler too - it's unclear which native and managed artifacts from the runtime pack you need to distribute with the embedder.

Also if you are building for multiple target architectures/OSes, you have to do step 2 per-RID. Our headers are the same on all architectures, so it's a bit unfortunate that you need to different include paths. (Of course when linking I don't think there's a way to avoid having per-arch library paths)

[steveisok]

Does it make sense to move the headers out of the runtime pack and into the embedded workload pack? We would have more control over the contents that way.

[srxqds]

hope this move to .net6 milestone

[lambdageek]

Found another issue on Linux (well, any non-OSX, I think). We set the SONAME to libmonosgen-2.0.so in the runtime pack, but name the file libcoreclr.so. As a result, any app linking against "libcoreclr" will end up with a dynamic linker reference to libmonosgen-2.0.so and then fail at runtime.

A heavyhanded solution is to use patchelf --set-soname libcoreclr.so libcoreclr.so but a better solution would be to update the runtime pack.

Filed a bug about it #49661