Skip to content

Conversation

@eiriktsarpalis
Copy link
Member

Following up on #104763, this PR makes the -arch parameter default to the OS architecture. I am not sure why we currently default to the current process architecture, but if I were to make a guess it's probably stemming from restrictions in older versions of Windows ARM when running emulated processes. In any case, I think we should change it because:

  1. It creates a footgun for ARM machine development where the default architecture can be unpredictable.
  2. Defaulting to the OS architecture makes windows builds consistent with UNIX builds.

@dotnet-policy-service
Copy link
Contributor

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

@eiriktsarpalis
Copy link
Member Author

cc @vcsjones

Copy link
Member

@jkotas jkotas left a comment

Choose a reason for hiding this comment

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

LGTM

Defaulting to the OS architecture makes windows builds consistent with UNIX builds.

Nit: I do not think that it is the case. If you run build in emulated environment (e.g. in x64 emulated shell on Apple Silicon), the build is going to default to the emulated architecture. uname -a that we use to detect the default architecture will return the emulated architecture, not the machine architecture: https://apple.stackexchange.com/questions/420452/running-uname-m-gives-x86-64-on-m1-mac-mini . I do not think there is anything to fix. The UNIX emulated environment tend to do a better job at keeping you inside it, and so it is not easy to get to the actual machine architecture.

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.

4 participants