Workaround broken ARM64X / MSVC_BUILD_AS_X builds #7827
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bogner
reviewed
Oct 16, 2025
remove unused original_li
bogner
approved these changes
Oct 16, 2025
Member
Author
|
@microsoft-github-policy-service rerun |
damyanp
added a commit
that referenced
this pull request
Oct 24, 2025
Currently, when internal pipelines build for ARM64X we use the older experimental `MSVC_BUILD_AS_X` feature. The latest VS release has regressed this functionality, resulting in the import libs for the ARM64 and ARM64X DLLs being written to the same location. Remember that ARM64X binaries are fat binaries containing both ARM64 and ARM64EC code. When building for ARM64 with MSVC_BUILD_AS_X, the Visual Studio cmake generator actually generates vcxproj files that build ARM64 and ARM64EC (with the ARM64EC version being the one that becomes the combined ARM64X binary. The generated project knows how to ensure that the ARM64 DLL is built to one location and the ARM64X one goes into the destination specified in the cmake scripts. However, the import libraries end up being configured to go into the same location, resulting in a race condition. Our cmake scripts have no knowledge of these two platforms, and so there's no direct way to address this. This workaround makes it so that when building in this mode the import libraries are written to a location containing `$(PLATFORM)`. This is a msbuild variable that's evaluated at build time. This is a short-term fix that allows us to unblock our internal pipelines. Longer-term we should move to using the [documented ARM64X approach](https://learn.microsoft.com/en-us/windows/arm/arm64x-build#building-an-arm64x-dll-with-cmake), at which point this change should be reverted. (cherry picked from commit ea7e910)
damyanp
added a commit
that referenced
this pull request
Oct 28, 2025
Since we last built this branch there have been various changes to the compilers and build images we use that require code updates to allow this to continue building. These changes impact our testing / building, or guide type checking in the compiler, and so are NFC as far as the product is concerned. ### Workaround broken ARM64X / MSVC_BUILD_AS_X builds (#7827) (cherry picked from commit ea7e910) ### Use WARP from nuget by default (#7427) (cherry picked from commit 33dd542) Manually moved changes from HlslExecTestUtils.h into ExecutionTest.cpp ### Add hctbuild.cmd parameter to specify the nuget config file (#7785) (cherry picked from commit 06dcb00) ### Change type of DiagnosticHandlerTy (cherry picked from commit b05a11a) ### Type safe version of MachinePassRegistry (cherry picked from commit 4ddee81) --------- Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> Co-authored-by: Justin Bogner <mail@justinbogner.com> Co-authored-by: Serge Guelton <sguelton@quarkslab.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, when internal pipelines build for ARM64X we use the older experimental
MSVC_BUILD_AS_Xfeature. The latest VS release has regressed this functionality, resulting in the import libs for the ARM64 and ARM64X DLLs being written to the same location.Remember that ARM64X binaries are fat binaries containing both ARM64 and ARM64EC code. When building for ARM64 with MSVC_BUILD_AS_X, the Visual Studio cmake generator actually generates vcxproj files that build ARM64 and ARM64EC (with the ARM64EC version being the one that becomes the combined ARM64X binary. The generated project knows how to ensure that the ARM64 DLL is built to one location and the ARM64X one goes into the destination specified in the cmake scripts. However, the import libraries end up being configured to go into the same location, resulting in a race condition.
Our cmake scripts have no knowledge of these two platforms, and so there's no direct way to address this. This workaround makes it so that when building in this mode the import libraries are written to a location containing
$(PLATFORM). This is a msbuild variable that's evaluated at build time.This is a short-term fix that allows us to unblock our internal pipelines. Longer-term we should move to using the documented ARM64X approach, at which point this change should be reverted.