Support building a mono-based .NET Runtime on x64 by omajid · Pull Request #68424 · dotnet/runtime

omajid · 2022-04-22T22:33:31Z

We now have some architectures (eg, s390x and ppc64le) that produce a .NET runtime that looks and feels like any other .NET runtime, except it's using Mono instead of CoreCLR under the hood.

However, it's only possible to produce this Mono-based .NET runtime on s390x/ppc64le. That makes it hard to test this set up on other architectures. Issues that affect the mono build on all architectures - such as #66594 become harder to fix and verify because of this unnecessary architecture requirement.

Fix that by adding a flag to the top-level build.sh (and also to the msbuild projects) to make it possible to produce a .NET runtime with Mono on any platform.

The default configuration is unchanged: we still produced CoreCLR-based .NET runtime on x64 and a Mono-based runtime on s390x/ppc64le.

Fixes: #62440

ghost · 2022-04-22T22:33:35Z

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

omajid · 2022-04-22T22:33:41Z

cc @directhex

ghost · 2022-04-23T02:58:32Z

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

Issue Details

We now have some architectures (eg, s390x) that produce a .NET runtime that looks and feels like any other .NET runtime, except it's using Mono instead of CoreCLR under the hood.

However, it's only possible to produce this Mono-based .NET runtime on s390x. That makes it hard to test this set up on other architectures. Issues that affect the mono build on all architectures - such as #66594 become harder to fix and verify because of this unnecessary architecture requirement.

Fix that by adding a flag to the top-level build.sh (and also to the msbuild projects) to make it possible to produce a .NET runtime with Mono on any platform.

The default configuration is unchanged: we still produced CoreCLR-based .NET runtime on x64 and a Mono-based runtime on s390x.

Fixes: #62440

Author:	omajid
Assignees:	-
Labels:	`area-Infrastructure`, `community-contribution`
Milestone:	-

tmds · 2022-04-25T06:54:00Z

You can simplify the condition by splitting it across a few lines.
<DefaultPrimaryRuntimeFlavor>CoreCLR<DefaultPrimaryRuntimeFlavor/> <DefaultPrimaryRuntimeFlavorCondition="'$(TargetArchitecture)' == 's390x'">Mono</DefaultPrimaryRuntimeFlavor> <DefaultPrimaryRuntimeFlavorCondition="'$(TargetArchitecture)' == 'armv6'">Mono</DefaultPrimaryRuntimeFlavor> <PrimaryRuntimeFlavorCondition="'$(PrimaryRuntimeFlavor)' == ''">$(DefaultPrimaryRuntimeFlavor)</PrimaryRuntimeFlavor>

ViktorHofer

Can you please document the PrimaryRuntimeFlavor switch? Especially, I would be interested in a section that explains when to use PrimaryRuntimeFlavor vs RuntimeFlavor.

omajid · 2022-04-25T16:41:15Z

Thanks for the feeback!

Can you please document the PrimaryRuntimeFlavor switch?

FWIW, this PR doesn't add it; the property already existed. We do make it possible for users to override it. The eng/Subsets.props documents it like this already:

 <!-- Determine the primary runtime flavor. This is usually CoreCLR, except on
platforms (like s390x) where only Mono is supported. The primary runtime
flavor is used to decide when to build the hosts and installers. -->

And the --help also adds:

 echo " -primaryRuntime Primary Runtime: CoreCLR or Mono. Unlike -runtimeFlavor, this produces a .NET-like"
echo " runtime (including tools, apphosts, etc) but uses either Mono or CoreCLR as the"
echo " actual runtime. Useful for building .NET on architectures without CoreCLR support,"
echo " or emulating the build for those architectures on x64."

What sort of detail are you looking for?

What would be a good place to document it?

omajid · 2022-04-25T17:18:04Z

Thanks to @tmds' comment (#62440 (comment)), I have learned that we don't need to adjust PrimaryRuntimeFlavor in the props file, we can simply pass in the correct value via msbuild property flag through build.sh - it will always override the property value defined in the props file. Is there any reason to add the conditionals to the .props file? I guess it makes things more explicit?

ViktorHofer · 2022-04-25T19:48:17Z

Don't we need a corresponding change in build.ps1 for Windows?

Yes, we do. I need to learn Windows/Powershell :'(

I don't have access to a Windows environment to fully test my changes, but I have used the powershell docker container image and Set-PSDebug -Trace 1 to confirm that
./eng/build.ps1 -primaryRuntime Mono -v d
Results in:
DEBUG: 1+ >>>> & "/runtime/eng/common/build.ps1" /p:TargetArchitecture=x64 -restore -build /p:PrimaryRuntimeFlavor=mono -verbosity d -configuration Debug

ghost · 2022-05-23T20:20:10Z

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

Issue Details

We now have some architectures (eg, s390x) that produce a .NET runtime that looks and feels like any other .NET runtime, except it's using Mono instead of CoreCLR under the hood.

However, it's only possible to produce this Mono-based .NET runtime on s390x. That makes it hard to test this set up on other architectures. Issues that affect the mono build on all architectures - such as #66594 become harder to fix and verify because of this unnecessary architecture requirement.

Fix that by adding a flag to the top-level build.sh (and also to the msbuild projects) to make it possible to produce a .NET runtime with Mono on any platform.

The default configuration is unchanged: we still produced CoreCLR-based .NET runtime on x64 and a Mono-based runtime on s390x.

Fixes: #62440

Author:	omajid
Assignees:	-
Labels:	`area-Infrastructure-mono`, `community-contribution`
Milestone:	-

ViktorHofer · 2022-05-30T15:11:05Z

There's a merge conflict in the PR. Apart from that, looks good.

tmds · 2022-06-01T04:29:44Z

fwiw, I still don't like this name. I had rather had an argument that captures this produces a .NET runtime.
We now have:
To build a .NET-like runtime that uses CoreCLR on x64:
./build.sh
To build mono on x64:
./build.sh -runtimeFlavor Mono
To build a .NET-like runtime that uses mono on x64:
./build.sh -runtimeFlavor Mono -primaryRuntime Mono
Undefined behavior:
./build.sh -primaryRuntime Mono

I agree. Do we really need a separate argument or could we say if you explicitly specify a runtimeFlavor then make that the primary runtime?

looks like this PR stalled a bit, what's our current thinking here?

I am not sure what the way forward here is.
As far as a I can tell, ./build.sh -primaryRuntime Mono is the same as ./build.sh -runtimeFlavor Mono: you get mono and nothing else.
I see @tmds's point about making things more complex, but I am not sure what the desired way forward is.
I think making runtimeFlavor the primary runtime is the opposite of what we want. We want to be able to produce a .NET runtime (what this PR was calling primaryRuntime) where the underlying runtime (aka runtimeFlavor) is mono, not CoreCLR.

Suggestion: add a flag named --mono-runtime with description Use the Mono runtime instead of the CoreCLR runtime..
The build scrip can use this to set PrimaryRuntimeFlavor/RuntimeFlavor as needed.
For the build script user, I think this provides a user-friendly option.

@akoeplinger what do you think about the suggestion?

I like the idea of --mono-runtime! I think "runtime" is a little ambiguous, though - I think we are building the .NET runtime with the Mono VM (instead of the Mono runtime with the Mono VM).

Sounds good. I think we could shorten it to just --mono.

Let's use the same name as source-build: --use-mono-runtime.
https://github.com/dotnet/dotnet/blob/2fc4462a30e08fe5eccb6dbc271a4297d2bba75f/build.sh#L12

steveisok · 2023-01-23T15:27:35Z

@omajid @tmds @akoeplinger This has been open for a while. Outside of resolving conflicts, what else needs resolved?

omajid · 2023-02-10T15:37:51Z

Outside of resolving conflicts, what else needs resolved?

I need to update this PR to use the new argument name that we have converged on.

akoeplinger · 2023-03-07T19:13:15Z

@omajid let me know if you need help resolving the conflicts :)

lewing · 2023-04-11T03:55:09Z

This is the oldest open pr now :)

We now have some architectures (eg, s390x) that produce a .NET runtime that looks and feels like any other .NET runtime, except it's using Mono instead of CoreCLR under the hood. However, it's only possible to produce this Mono-based .NET runtime on a select few architectures. That makes it hard to test this set up on other architectures. Issues that affect the mono build on all architectures - such as dotnet#66594 become harder to fix and verify because of this unnecessary architecture requirement. Fix that by adding a flag to the top-level build.sh (and also to the msbuild projects) to make it possible to produce a .NET runtime with Mono on any platform. The default configuration is unchanged: we still produced CoreCLR-based .NET runtime on x64 and a Mono-based runtime on arm32,ppc64le,s390x. Fixes: dotnet#62440

omajid · 2023-04-12T15:38:22Z

I have updated the PR. Anyone willing to review it?

tmds · 2023-04-12T16:03:50Z

 shift 2
 ;;

+ -usemonoruntime)


The vmr option is --use-mono-runtime. Can you use the exact same name?

Good point! The rest of the options in the runtime build.sh use a completely different convention, though (eg outputrid, keepnativesymbols). Whatever I go with, it will look out of place with the other convention :(
Since this option lives in build.sh, I tried to keep it consistent with the other options in build.sh.
I am happy to change it if it's okay with the runtime maintainers.

Sounds reasonable to me

Is that a "keeping it with current runtime convention sounds reasonable to me" or a "making it match the option in vmr sounds reasonable to me" ? 😄

I'm fine leaving out the dashes. I didn't realize you had done it to be consistent with the other arguments.

I'm fine with the current state too.

marek-safar · 2023-05-01T07:56:52Z

@directhex @akoeplinger could you please help landing this PR

akoeplinger · 2023-05-03T13:05:56Z

Thank you!

ghost added the community-contribution Indicates that the PR has been added by a community member label Apr 22, 2022

omajid force-pushed the mono-x64-primary-runtime-flavor branch from a5e2a26 to 4ab4e75Compare April 22, 2022 22:35

AaronRobinsonMSFT added the area-Infrastructure label Apr 23, 2022

tmds reviewed Apr 25, 2022
View reviewed changes

ViktorHofer reviewed Apr 25, 2022
View reviewed changes

jeffschwMSFT added area-Infrastructure-mono and removed area-Infrastructure labels May 23, 2022

omajid force-pushed the mono-x64-primary-runtime-flavor branch from 4ab4e75 to 6fbb9deCompare May 30, 2022 14:55

omajid force-pushed the mono-x64-primary-runtime-flavor branch from 6fbb9de to b49c0f0Compare May 30, 2022 16:05

tmds reviewed Jun 1, 2022
View reviewed changes

This was referenced Oct 3, 2022
System.InsufficientExecutionStackException when using Mono on linux-musl#76523
Closed
[release/6.0] CompilerServer: fatal error - server reports different hash version than build task on linux-musl when using mono-backed runtime #76543
Closed

tmds mentioned this pull request Nov 3, 2022
source-build: set the properties to build for mono runtime. #77786
Merged

tmds mentioned this pull request Feb 10, 2023
Make DotNetBuildFromSource work in more cases. #81480
Merged

omajid force-pushed the mono-x64-primary-runtime-flavor branch from b49c0f0 to 25fdd52Compare April 11, 2023 16:47

omajid closed this Apr 11, 2023

omajid reopened this Apr 11, 2023

tmds reviewed Apr 12, 2023
View reviewed changes

lewing requested a review from steveisok April 26, 2023 02:13

akoeplinger approved these changes May 3, 2023
View reviewed changes

akoeplinger merged commit fc22ee9 into dotnet:mainMay 3, 2023

ghost locked as resolved and limited conversation to collaborators Jun 3, 2023

Uh oh!

Conversation

omajid commented Apr 22, 2022• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ghost commented Apr 22, 2022

Uh oh!

omajid commented Apr 22, 2022

Uh oh!

ghost commented Apr 23, 2022

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ViktorHofer left a comment

Choose a reason for hiding this comment

Uh oh!

omajid commented Apr 25, 2022

Uh oh!

omajid commented Apr 25, 2022• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ghost commented May 23, 2022

Uh oh!

ViktorHofer commented May 30, 2022

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

omajidAug 30, 2022• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tmdsAug 31, 2022• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

steveisok commented Jan 23, 2023

Uh oh!

omajid commented Feb 10, 2023

Uh oh!

akoeplinger commented Mar 7, 2023

Uh oh!

lewing commented Apr 11, 2023

Uh oh!

omajid commented Apr 12, 2023

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

marek-safar commented May 1, 2023

Uh oh!

akoeplinger commented May 3, 2023

Uh oh!

Reviewers

omajid commented Apr 22, 2022•
edited
Loading

omajid commented Apr 25, 2022•
edited
Loading

omajidAug 30, 2022•
edited
Loading

tmdsAug 31, 2022•
edited
Loading