Ship a .framework version of Mono #53370

directhex · 2021-05-27T17:31:28Z

This is based on initial work by @akoeplinger, who did most of the CMake bits

lambdageek · 2021-05-27T17:46:51Z

src/mono/mono/mini/CMakeLists.txt

+      set_property(TARGET mono-framework APPEND_STRING PROPERTY LINKER_LANGUAGE CXX)
+    endif ()
+    set_property(TARGET mono-framework APPEND_STRING PROPERTY LINK_FLAGS " -Wl,-compatibility_version -Wl,2.0 -Wl,-current_version -Wl,2.0")
+    target_sources(mono-framework PRIVATE "${mono-components-objects}")


So this is going to be a mono framework for ios/tvos/catalyst that always statically links in the full non-stub versions of all the components. Is that what we want? We always want to support hot reload and diagnostics, @rolfbjarne ?

Or should each component be its own dynamic .framework, too? (in which case... it would be upto the xamarin-macios embedding code to hook mono_dl_open and locate the components for us)

Or maybe one mono.framework with all the components, and one with only stubs?

statically links

I have not read the PR yet... but the goal of a .framework is that it's all dynamic (not static) linking

yea mono is built as a dynamic thing, but it will include all the components statically as part of it. I left some comments on the Paper.

Isn't there a hard limit to the number of .frameworks an app can have?

We always want to support hot reload and diagnostics,

Debug

We do not care about the app bundle size [1]

IOW all features (including HR and diagnostics) can be available in the binary (and be enabled/disabled by the app if required)

We care about build and deploy times

dynamic linking (used for frameworks) makes the build faster

the framework (binary) will rarely change (deployed to sim/device once)

[1] unless it starts affecting build/deploy times :-)

Release

We care about the app bundle size

by default, we won't be using the .framework

using the static libraries .a allows the native linker / strip to remove a lot of code. Using the framework would create much larger apps.

a release .framework is needed for app extensions

why ? it's smaller to share a single, larger .framework than to have a (even partial) runtime in 2 (or more) executables - main app and one/several extension(s)

We do not care (within limits) about build times. Release builds being less common than debug ones

We do not care about deploy times. Since release build are smaller then generally deploy faster anyway.

I do not see "hot reload" needed for release builds. Not entirely sure about "diagnostics" ...

Modularity is more important for the static libraries. The majority of apps ships without extensions (but that could change).

Or should each component be its own dynamic .framework, too?

There's a limit (at least a suggested one, never seen a rejection) to the number of user frameworks that an app should have. However a framework can have several dynamic libraries inside it... so we could control what's in or out.

Not sure if that's really needed...

Given there are quite a number of conditions and cases I wonder if it'd make more sense for Xamarin.iOS to create the .framework as part of the build when it is needed with just the right components? E.g. I've heard that we have some requirements to not ship the diagnostics TCP server code in release builds, even if it is not used.

We can create Mono.framework, but afaik we can't create the corresponding dSYM, that has to be done on the machine that compiled the object files.

I've done some work relating to debug symbol generation in #53240

dsyms for anything we generate and put in a nupkg should be available from the MS debug symbol service

@rolfbjarne we do have the dSYM's and can put them into the runtime pack (or the symbols nuget), would you mind trying if you can create the .framework based off of that?

@akoeplinger I created a very simple test case, and I was able to create a .framework and the corresponding .framework.dSYM from a .dylib and its corresponding .dylib.dSYM. I ran an executable that consumed the .framework in lldb, and lldb was able to symbolicate functions in the .framework. I wasn't able to make macOS' crash reporter symbolicate the framework functions though, so I'm not sure if the end result is actually correct, or if it just happens to work in lldb. One point is that Apple identifies .dSYM directories using a UUID (which shows up in the crash report), and if we create the .framework.dSYM from the .dylib.dSYM, those share the same UUID, and potentially things break.

spouliot

By the PR itself it's not clear to me what ends up inside that directory ?

Any chance for someone to zip this up and attach it here ? thanks!

src/installer/pkg/sfx/Microsoft.NETCore.App/Microsoft.NETCore.App.Runtime.props

directhex · 2021-05-27T17:59:27Z

@spouliot

unzip -lf /Users/directhex/Projects/runtime/artifacts/packages/Debug/Shipping/Microsoft.NETCore.App.Runtime.Mono.ios-arm64.6.0.0-dev.nupkg | grep mo
no-framework
      765  05-27-2021 16:30   runtimes/ios-arm64/native/mono-framework.framework/Info.plist
  8100608  05-27-2021 16:30   runtimes/ios-arm64/native/mono-framework.framework/mono-framework

Except it's different on Catalyst, which is why Catalyst builds are breaking (I'm not accounting for stuff winding up in a more complex tree)

vargaz · 2021-05-27T18:52:46Z

src/mono/mono/mini/CMakeLists.txt

+
+
+  if(TARGET_DARWIN)
+    add_library(mono-framework SHARED $<TARGET_OBJECTS:monosgen-objects>)


Can we add a conditional flag so its only built when building from mono.proj ?

lambdageek · 2021-06-18T15:47:04Z

We had a call about runtime components, and basically I think this is what we want:

iOS Simulator runtime pack should include:

Mono.framework that includes all the components linked into the libmono that is in the framework. (can do dynamic linking on the simulator, we can put shared libs of the components into the Mono.framework so we build the runtime the same way for .framework and non-.framework)
the same native directory as today (libmono built with dynamic component support, native libs, shared libraries of the components) to be used if users choose non-default options

iOS Device runtime pack should include:

Mono.framework for release/publish (libmono built with static component support and with only component stubs linked into it) that will be used for the app extension scenario that Sebastien outlined.
Mono.framework for debug (libmono built with static component support and with all the components, not the stubs, linked into it)
the same native directory as today (libmono, native libs, static libs of the components and of the stubs) to be used by default for release builds that don't need to share mono between an app and extensions. (Usually they will link the component stubs)

…os-xcframework

directhex · 2021-07-02T16:48:14Z

@lambdageek @rolfbjarne okay, how's that?

src/mono/mono/mini/CMakeLists.txt

lewing · 2021-07-06T17:13:23Z

Are you sure about using Zip, a format which doens't really handle symlinks

The zip format handles symlinks just fine in my experience. We already use it to compress frameworks into a zip file when dealing with user frameworks in binding libraries.

It's the BCL's API for working with zip files that can't handle symlinks, the command line zip tool works.

It would be really nice to fix this. It is causing problems in several places that are difficult to resolve any other way.

directhex · 2021-07-06T17:16:44Z

@lewing probably comes under the heading of #54253

lewing · 2021-07-06T17:17:28Z

@lewing probably comes under the heading of #54253

and NuGet/Home#10734 for some of the other cases

…I lanes

directhex · 2021-07-07T16:44:40Z

Official build working as planned

unzip -lf ~/Downloads/Microsoft.NETCore.App.Runtime.Mono.maccatalyst-arm64.6.0.0-preview.7.21357.6.nupkg | grep fram
      763  07-07-2021 14:17   runtimes/maccatalyst-arm64/native/Mono.release.framework/Info.plist
  6475728  07-07-2021 14:21   runtimes/maccatalyst-arm64/native/Mono.release.framework/Mono
      761  07-07-2021 14:17   runtimes/maccatalyst-arm64/native/Mono.debug.framework/Info.plist
  6188776  07-07-2021 14:21   runtimes/maccatalyst-arm64/native/Mono.debug.framework/Mono

eng/pipelines/mono/templates/build-job.yml

src/mono/mono.proj

lambdageek · 2021-07-07T18:13:51Z

src/mono/mono/mini/CMakeLists.txt

@@ -381,6 +381,42 @@ if(NOT DISABLE_SHARED_LIBS)
    add_library(monosgen-shared-dac SHARED "mini-windows-dlldac.c")
    set_target_properties(monosgen-shared-dac PROPERTIES OUTPUT_NAME ${MONO_SHARED_LIB_NAME}-dac)
  endif()
+
+  if(BUILD_DARWIN_FRAMEWORKS)
+    if(TARGET_DARWIN)


I think this should be TARGET_DARWIN AND STATIC_COMPONENTS.
I think this version of the code is only right if the components are static archives, right?

So we should never build a .framework in the case of .dylib components? Didn't you say iOS Simulator should ship dylibs & build against stubs in #53370 (comment) ?

Sorry, I meant to me this looks like the code only supports the static components case. I assumed a dynamic components version will be added in a follow-up PR. Maybe I misunderstood what's happening here.

src/mono/mono/mini/CMakeLists.txt

…tubs)

lambdageek

In general, LGTM.

I think there are a couple of follow-up things we need to do (/cc @steveisok):

i'm still unclear if this supports dynamic (.dylib) components inside the .framework (which we want for the simulator case). if it doesn't that's a follow-up item (together with switching simulator runs to using dynamic components)
We should update AppleAppBuilder to support frameworks and add a functional test.

directhex · 2021-07-08T19:27:24Z

@lambdageek we can't afford to wait on Rolf returning before iterating on this, given the snap date, so I'll merge it as-is and we can follow up for any changes as it's shown they're needed.

Of your two followup concerns:

Dynamic components are copied into the .framework if they exist, but it's not clear they're in the correct path to be usable (I can't find a consistent reference on the correct path for dylibs in iOS-style unversioned frameworks)
Not included in this PR, will need to be future work

akoeplinger and others added 5 commits May 17, 2021 12:43

WIP

3d876f7

Merge remote-tracking branch 'origin/main' into ios-xcframework

ada980d

Copy mono-framework.framework to same build dir as monosgen

82555d5

Copy .frameworks to bin/

4879ec7

Ship .framework in nupkg

9e3bc17

directhex added area-Build-mono os-ios Apple iOS os-tvos Apple tvOS os-maccatalyst MacCatalyst OS labels May 27, 2021

directhex requested review from rolfbjarne, spouliot and steveisok May 27, 2021 17:31

directhex requested review from CoffeeFlux, imhameed, lambdageek, marek-safar, SamMonoRT and vargaz as code owners May 27, 2021 17:31

lambdageek reviewed May 27, 2021

View reviewed changes

spouliot reviewed May 27, 2021

View reviewed changes

src/installer/pkg/sfx/Microsoft.NETCore.App/Microsoft.NETCore.App.Runtime.props Outdated Show resolved Hide resolved

vargaz reviewed May 27, 2021

View reviewed changes

directhex added 2 commits June 3, 2021 09:00

Merge remote-tracking branch 'origin/main' into ios-xcframework

ff168f9

Rename mono-framework to Mono

f97e186

spouliot mentioned this pull request Jun 23, 2021

[.NET 6] External dotnet issues xamarin/xamarin-macios#8901

Closed

61 tasks

directhex added 4 commits June 29, 2021 12:51

Merge remote-tracking branch 'origin/main' into ios-xcframework

0ee1330

Fix framework build on non-catalyst

7d8d578

Build stubby (release) and static-component (release) .frameworks

e97ec4c

Merge remote-tracking branch 'origin/main' into ios-xcframework

f16eabb

directhex added 4 commits July 2, 2021 09:43

Fix stripping-dwarf-files bug

4ee0938

Merge remote-tracking branch 'origin/main' into ios-xcframework

45f4e2b

Merge branch 'ios-xcframework' of github.com:directhex/runtime into i…

3315ef6

…os-xcframework

Bundle dylibs for components on dynamic component platforms

8f544ab

vargaz reviewed Jul 6, 2021

View reviewed changes

src/mono/mono/mini/CMakeLists.txt Outdated Show resolved Hide resolved

vargaz reviewed Jul 6, 2021

View reviewed changes

src/mono/mono/mini/CMakeLists.txt Outdated Show resolved Hide resolved

directhex added 3 commits July 6, 2021 16:18

Only build .frameworks if explicitly turned on; turn on in relevant C…

db386ee

…I lanes

Merge remote-tracking branch 'origin/main' into ios-xcframework

aa31a96

Typo

62ab8ae

steveisok approved these changes Jul 7, 2021

View reviewed changes

mdh1418 reviewed Jul 7, 2021

View reviewed changes

eng/pipelines/mono/templates/build-job.yml Outdated Show resolved Hide resolved

mdh1418 reviewed Jul 7, 2021

View reviewed changes

src/mono/mono.proj Show resolved Hide resolved

lambdageek reviewed Jul 7, 2021

View reviewed changes

src/mono/mono/mini/CMakeLists.txt Show resolved Hide resolved

lambdageek reviewed Jul 7, 2021

View reviewed changes

src/mono/mono/mini/CMakeLists.txt Outdated Show resolved Hide resolved

directhex added 3 commits July 7, 2021 14:26

Fix casing (from Mitch)

2837fcb

Add explanation of whitespace fiddling to bypass cmake list limitations

65e00a7

Release and debug were reversed (debug should get full objects, not s…

29e9413

…tubs)

lambdageek approved these changes Jul 7, 2021

View reviewed changes

Merge remote-tracking branch 'origin/main' into ios-xcframework

bd8272e

directhex merged commit d841f5e into dotnet:main Jul 8, 2021

ManickaP mentioned this pull request Jul 20, 2021

[QUIC] Remove AppContext switch from S.N.Quic #56027

Merged

karelz mentioned this pull request Jul 28, 2021

[WinHttpHandler] Long running test: ResponseHeadersRead_SynchronizationContextNotUsedByHandler on Win7/Win8 #54034

Closed

ghost locked as resolved and limited conversation to collaborators Aug 7, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Ship a .framework version of Mono #53370

Ship a .framework version of Mono #53370

directhex commented May 27, 2021

lambdageek May 27, 2021 •

edited

Loading

spouliot May 27, 2021

lambdageek May 27, 2021

steveisok May 27, 2021

spouliot May 27, 2021

akoeplinger Jun 1, 2021

rolfbjarne Jun 1, 2021

directhex Jun 1, 2021

akoeplinger Jun 1, 2021

rolfbjarne Jun 18, 2021

spouliot left a comment

directhex commented May 27, 2021

vargaz May 27, 2021

lambdageek commented Jun 18, 2021 •

edited

Loading

directhex commented Jul 2, 2021

lewing commented Jul 6, 2021 •

edited

Loading

directhex commented Jul 6, 2021

lewing commented Jul 6, 2021 •

edited

Loading

directhex commented Jul 7, 2021

lambdageek Jul 7, 2021

directhex Jul 7, 2021

lambdageek Jul 7, 2021

lambdageek left a comment

directhex commented Jul 8, 2021



		if(TARGET_DARWIN)
		add_library(mono-framework SHARED $<TARGET_OBJECTS:monosgen-objects>)

Ship a .framework version of Mono #53370

Ship a .framework version of Mono #53370

Conversation

directhex commented May 27, 2021

lambdageek May 27, 2021 • edited Loading

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

Debug

Release

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

spouliot left a comment

Choose a reason for hiding this comment

directhex commented May 27, 2021

Choose a reason for hiding this comment

lambdageek commented Jun 18, 2021 • edited Loading

directhex commented Jul 2, 2021

lewing commented Jul 6, 2021 • edited Loading

directhex commented Jul 6, 2021

lewing commented Jul 6, 2021 • edited Loading

directhex commented Jul 7, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lambdageek left a comment

Choose a reason for hiding this comment

directhex commented Jul 8, 2021

lambdageek May 27, 2021 •

edited

Loading

lambdageek commented Jun 18, 2021 •

edited

Loading

lewing commented Jul 6, 2021 •

edited

Loading

lewing commented Jul 6, 2021 •

edited

Loading