Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for multi-arch install locations #53763

Merged
merged 23 commits into from
Jun 23, 2021
Merged

Conversation

mateoatr
Copy link
Contributor

@mateoatr mateoatr commented Jun 5, 2021

This PR implements the accepted design for multi-arch install locations. It adds the ability for Unix users to specify architecture-specific install locations in the install location config file (located in /etc/dotnet/install_location); this file currently contains a single line pointing to the registered install location.

Changes in this PR evolve the format of the aforementioned config file so that users are now able to specify multiple architecture-specific install locations and, optionally, keep the first line as it currently is (i.e., without any architecture prefix) -- this will be needed for backcompat with previous apphosts and will also work as the fallback install location if none of the arch install locations can be resolved.

This PR also gives users the ability to set architecture-specific environment variables for specifying the location of the .NET runtime by extending the current format to DOTNET_ROOT_ARCH. The current format, DOTNET_ROOT (and DOTNET_ROOT(x86) on Windows), will continue to be supported and will work as a fallback when no arch-specific env vars are used.

Currently on Windows x86, the only environment variable that is looked for finding the install location is DOTNET_ROOT(x86), changes in this PR will cause to fallback to DOTNET_ROOT whenever DOTNET_ROOT(x86) is not set in win-x86.

@ghost
Copy link

ghost commented Jun 5, 2021

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

Issue Details
Author: mateoatr
Assignees: -
Labels:

area-Host

Milestone: -

src/native/corehost/hostmisc/pal.unix.cpp Outdated Show resolved Hide resolved
src/native/corehost/hostmisc/pal.unix.cpp Outdated Show resolved Hide resolved
src/native/corehost/hostmisc/pal.unix.cpp Outdated Show resolved Hide resolved
src/native/corehost/hostmisc/pal.unix.cpp Show resolved Hide resolved
src/native/corehost/hostmisc/utils.cpp Outdated Show resolved Hide resolved
src/native/corehost/hostmisc/pal.unix.cpp Outdated Show resolved Hide resolved
is_first_line = false;
}

if (architecture_install_location != "")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the config file looks like this on x64 machine:

/default/path
x64=

The result will be to use /default/path. I'm not sure I like that. The user did specify arch specific path, it's just invalid. Basically I think this should be a very similar behavior to something like:

/default/path
x64=////nonsense///

Both cases should fail with error saying that the root path is invalid (doesn't exist).

There's also this case:

x64=/dotnet/x64

(the first line is empty). If we're running on arm64 - it should fail, the only question is if it should fail with the "Did not find any install location" or "Install location '' doesn't exist".
(Note that existing apphost will fail with the latter).

src/native/corehost/hostmisc/utils.cpp Outdated Show resolved Hide resolved
src/native/corehost/hostmisc/utils.cpp Outdated Show resolved Hide resolved
src/native/corehost/hostmisc/pal.unix.cpp Show resolved Hide resolved
src/native/corehost/hostmisc/utils.cpp Outdated Show resolved Hide resolved
@mateoatr mateoatr marked this pull request as ready for review June 14, 2021 19:19
Copy link
Member

@vitek-karas vitek-karas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. One final ask - try to test this in the real world Apple M1 scenario:

  • Install 6.0 arm64 preview into /usr/local/share/dotnet
  • Install 5.0 x64 preview into /usr/local/share/dotnet/x64
  • Write /etc/dotnet/install_location with content:
    /usr/local/share/dotnet/x64
    arm64=/usr/local/share/dotnet
  • Try to run osx-arm64 net6.0 apphost app (should need this change to work)
  • Try to run osx-x64 net5.0 apphost app (should work as shipped)

src/native/corehost/hostmisc/pal.unix.cpp Outdated Show resolved Hide resolved
src/native/corehost/hostmisc/pal.h Outdated Show resolved Hide resolved
src/native/corehost/hostmisc/utils.cpp Outdated Show resolved Hide resolved
src/native/corehost/hostmisc/pal.unix.cpp Outdated Show resolved Hide resolved
src/native/corehost/hostmisc/pal.unix.cpp Show resolved Hide resolved
Copy link
Member

@elinor-fung elinor-fung left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me.

Last question - this PR doesn't mention the multi-arch support using the registry on Windows. While looking at this PR, I noticed that it is currently only for x86 and x64:

bool pal::get_dotnet_self_registered_dir(pal::string_t* recv)
{
#if !defined(TARGET_AMD64) && !defined(TARGET_X86)
// Self-registered SDK installation directory is only supported for x64 and x86 architectures.
return false;

bool pal::get_dotnet_self_registered_config_location(pal::string_t* recv)
{
#if !defined(TARGET_AMD64) && !defined(TARGET_X86)
return false;

Is there separate work/testing for that?

@vitek-karas
Copy link
Member

Thanks a lot @elinor-fung for finding the Windows issue. That must be fixed (and tests added) as well. But feel free to do that in a separate PR>

@mateoatr
Copy link
Contributor Author

Tested the above scenarios locally on an M1 -- everything working. CI failures here seem unrelated; for instance, retriggering the Build Android x64 Release AllSubsets_Mono_RuntimeTests pipeline resulted in no failures.

@mateoatr mateoatr merged commit 97de5c5 into dotnet:main Jun 23, 2021
@mateoatr
Copy link
Contributor Author

Is there separate work/testing for that?

I'm taking a look at this. I added this item in the tracking issue that we have for the multi-arch installer support (#50798).

thaystg added a commit to thaystg/runtime that referenced this pull request Jun 23, 2021
…nitial_config

* origin/main: (362 commits)
  [wasm][debugger] Reuse debugger-agent on wasm debugger (dotnet#52300)
  Put Crossgen2 in sync with dotnet#54235 (dotnet#54438)
  Move System.Object serialization to ObjectConverter (dotnet#54436)
  Move setting fHasVirtualStaticMethods out of sanity check section (dotnet#54574)
  [wasm] Compile .bc->.o in parallel, before passing to the linker (dotnet#54053)
  Change PathInternal.IsCaseSensitive to a constant (dotnet#54340)
  Make mono_polling_required a public symbol (dotnet#54592)
  Respect EventSource::IsSupported setting in more codepaths (dotnet#51977)
  Root ComActivator for hosting (dotnet#54524)
  Add ILLink annotations to S.D.Common related to DbConnectionStringBuilder (dotnet#54280)
  Fix finalizer issue with regions (dotnet#54550)
  Add support for multi-arch install locations (dotnet#53763)
  Update library testing docs page to reduce confusion (dotnet#54324)
  [FileStream] handle UNC and device paths (dotnet#54483)
  Update NetAnalyzers version (dotnet#54511)
  Added runtime dependency to fix the intermittent test failures (dotnet#54587)
  Disable failing System.Reflection.Tests.ModuleTests.GetMethods (dotnet#54564)
  [wasm] Move AOT builds from `runtime-staging` to `runtime` (dotnet#54577)
  Keep obj node for ArrayIndex. (dotnet#54584)
  Disable another failing MemoryCache test (dotnet#54578)
  ...
@ghost ghost locked as resolved and limited conversation to collaborators Jul 23, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants