Support building for arm64 on arm64 (*nix)

[omajid]

This commit allows ASP.NET Core to be built on arm64 machines directly, without relying on cross-compilation.

There's a few changes in here:

1. Extend build.sh to handle non-x64 architectures.

   By default, the build assumes the machine is x64. Instead query the machine (using uname) to find out what the actual build machine is.

   A similar change was made in arcade: Handle non-x86 in dotnet-install.sh on *nix arcade#4132

2. Ask msbuild to handle the BuildArchitecture

   By default, our build systems assums the machine is x64. This modifies the build configuration to check the architecture of the currently running build machine, and set BuildArchitecture to that.

   Ideally, we could just use ProcessorArchitecture on all cases and avoid any hardcoding of x64, but that would break Visual Studio. Visual Studio runs msbuild as a x86 process and we need to explicitly tell msbuild to target x64 in those cases.

   We ran into a similar issue in corefx: Revert "Enable build on hosted arm64" corefx#40427

   The final fix was: Enable build on hosted arm64 corefx#40453

3. Fix crossgen in Microsoft.AspNetCore.App.Runtime

   We run crossgen for supported architectures (including x64 and arm64). For that, we need a jit that we can point crossgen to. Generally, we can rely on the build scripts to find the right libclrjit.so. However, arm64 has multiple libclirjit.so, for different use-cases. There's one for arm64 (for running on arm64) and there's another one for cross-compiling for arm64 on x64. We need to figure out and use the right one explicitly rather than assuming the right one gets picked up.

   See Enable building for arm64 on arm64 core-setup#8468 for similar changes made in core-setup.

This also needs #14790 to fully work on arm64.

[pranavkm]

Thanks for the PR @omajid. Have you looked at the build failures introduced by your change?

[omajid]

No, I hadn't. Looking at them now.

[omajid]

@pranavkm I fixed the errors that I could spot.

I am not sure what this new Helix ARM64 failure is.

Microsoft.AspNetCore.Mvc.TagHelpers.CacheTagHelperTest.Microsoft.AspNetCore.Mvc.TagHelpers.CacheTagHelperTest.ProcessAsync_AwaitersUseTheResultOfExecutor

That isn't anything my patch touches... is this a known issue?

[pranavkm]

@aspnet-hello triage https://dev.azure.com/dnceng/public/_build/results?buildId=401027&view=ms.vss-test-web.build-test-results-tab

[aspnet-hello]

This comment was made automatically. If there is a problem contact aspnetcore-build@microsoft.com.

I've triaged the above build. I've created/commented on the following issue(s)
https://github.com/aspnet/AspNetCore-Internal/issues/3294

[omajid]

@pranavkm I don't have access to aspnet/AspNetCore-Internal. Please let me know if anything in that issues requires me to do something here.

[omajid]

Ping. Anyone willing to review this?

[omajid]

@dleeapho Hey, do you know someone who can help shepherd this change through?

[omajid]

Ping. Anyone willing to review this?

[omajid]

Hey @leecow, any suggestions on who I can poke to get this PR reviewed? It's part of the patches we are trying to add to source-build for arm64 support: dotnet/source-build#1300

[crummel]

Hi @JunTaoLuo, could you or someone else take a look at this? Omair has this patched into source-build right now so I think it should be pretty close.

[JunTaoLuo]

This approach is different from what we have been doing so far. We specify --arch explicitly in most cases: https://github.com/aspnet/AspNetCore/blob/master/.azure/pipelines/ci.yml#L345. The reason for this is that we would be able to build ARM on a non-ARM machine for example. Is it not possible to do so in source build? The changes in Microsoft.AspNetCore.App.Runtime.csproj look good but I'm unsure we need the other changes.

[omajid]

Hi @JunTaoLuo ! Thanks for the review!

This approach is different from what we have been doing so far.

I think the approach here isn't so different as you might think at first.

Before this change, a developer can build AspNetCore for their local architecture (eg, build for x64 for x64) by using just ./build.sh. A developer can also cross-compile (build for arm64 on x64, or build for x86 on x64) by using ./build.sh --arch .... As I see it, ./build.sh does the right thing for your architecture and you only need to pass --arch if you are cross compiling.

This change simply extends this concept. It now makes the the build system put arm64 in the same category as x64: a developer can simply run ./build.sh on a arm64 box and get the right result without having to pass any special arguments or treat arm64 differently than x64.

As far as I can tell, we are not changing what happens on cross compilation: a user still needs to pass --arch to compile for an architecture different than the currently active one (eg, build for arm64 on x64).

Is it not possible to do so in source build?

The goal of source-build is to eventually package up and include .NET Core (including ASP.NET Core) into various Linux - and other *nix - distributions. They generally support many, many more platforms than .NET Core currently does. And it's more common to build on the same architecture as the target architecture rather than cross compiling. They build for ppc64le on ppc64le, for example, instead of cross compiling for ppc64le on x64. In that context, adding special cases for every architecture and computing/passing the right --arch manually is a bit more difficult than ASP.NET Core just doing the right thing itself when it realizes it is running on a specific platform.

[JunTaoLuo]

My understanding was shaped by https://github.com/aspnet/AspNetCore/blob/master/docs/BuildFromSource.md#build-properties which suggests that we let the user (or build script) explicitly specify what to build for.

That being said, my initial concerns are abated because:

1. This is 5.0 so there's no impact on 3.0 servicing or 3.1 builds that are currently underway
2. I checked our ci configuration and we explicitly specify --arch as needed so there should be no regression due to this change.

Although the changes look correct, I'm still not convinced it's difficult to specify these variables as part of the build script by the user. Which other platforms are we planning to support in 5.0?

[omajid]

My understanding was shaped by https://github.com/aspnet/AspNetCore/blob/master/docs/BuildFromSource.md#build-properties which suggests that we let the user (or build script) explicitly specify what to build for.

Thanks for this pointer. I wasn't aware of this position. I still think my change is a better idea because does the right thing to correctly build ASP.NET Core on arm64, even outside of source-build.

cc @crummel @dleeapho @dseefeld. Any thoughts on what the right approach here might be? Is it expected to pass TargetArchitectures explicitly from source-build?

This is 5.0 so there's no impact on 3.0 servicing or 3.1 builds that are currently underway

If it helps, I have been testing 3.0 with this change 😄 . All my normal end-to-end tests with the SDK pass on arm64. I think the plan is to carry this change as a local patch in 3.1 for source-build.

I checked our ci configuration and we explicitly specify --arch as needed so there should be no regression due to this change.

I would hope there wouldn't be any change here. It only changes the behaviour when you are building on an arm64 box. The CI machines are x64 and so this change should be functionally no-op (aside from any bugs I introduced).

Although the changes look correct, I'm still not convinced it's difficult to specify these variables as part of the build script by the user.

I think I agree. It's not difficult, just more error prone and a point of divergence from x64 where ./build.sh does the right thing.

Which other platforms are we planning to support in 5.0?

I have no plans for any other platforms whatsoever. I just want to keep things flexible where possible.

[crummel]

Is it expected to pass TargetArchitectures explicitly from source-build?

This is generally our preference. Source-build tries not to rely on defaults because we aren't in control of when they change (this is less of a problem now that most repos are on Arcade and have the same defaults).

[omajid]

@JunTaoLuo Any thoughts? What would it take to get this to be mergable? Would you like me to drop all changes to ./build.sh and require TargetArchitecture to be set explicitly?

[JunTaoLuo]

It looks like the preference for source build is to specify these explicitly so I think we should not be taking the changes in builds.sh and TargetArchitecture. We can merge the Microsoft.AspNetCore.App.Runtime changes though.

[omajid]

@JunTaoLuo Please let me know if this is okay to merge.

[omajid]

CI looks good to me; "Pull Request Labeller" failed, but I guess that isn't about the code at all.

[JunTaoLuo]

Thanks @omajid !

[omajid]

Thanks for reviewing and merging this!

[omajid]

@crummel Just as an FYI: source-build invokes the ASP.NET Core build with ./build.sh .... Adding a /p:TargetArchitecture=arm64 doesn't work because ./build.sh itself appends -p:TargetArchitecture=x64 later on, which overrides the arm64 :(

./build.sh --arch arm64 looks like a possible workaround, but overriding via TargetArchitecture seems broken.