-
Notifications
You must be signed in to change notification settings - Fork 93
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 arm64 architecture to the shared store #2181
Comments
One possibility is to create symbolic links to a single architecture since we use the same IL-only components. |
Today, even I was exploring about symbolic link. If we get this working we could reduce our package size by and solve issues for all architecture. |
I am not sure if it will be good idea to support only managed code on arm64. |
Removing from 1.0.0-rc milestone. I think that we can add this support after 1.0.0 release, both for sourcecode and bytecode instrumenation. I would like to avoid only partial support. |
The list at dotnet/runtime has other values but because of Apple M1 boxes, we may want to provide
arm64
by default.Adding all
arch
to the shared store doesn't seem scalable, ideally, we would have a way to automatically select the proper|arch|/|tfm|
pair upon installing on the box. However, as mentioned,arm64
may be popular enough to justify its addition even without the general mechanism.Temporary Workaround: rename
$DOTNET_SHARED_STORE/x64/
to$DOTNET_SHARED_STORE/arm64/
. The assemblies under the folder are IL only so source instrumentations are expected to work without issues. The native component is not supported on arm64 yet and given that the default rule engine will fail startup if it is enabled it needs to be disabled removing or setting the environment variableCORECLR_ENABLE_PROFILING
to0
.[EDIT 01: Update workaround since it is not going to work with the default rule engine checks.]
The text was updated successfully, but these errors were encountered: