Fix native builds on Windows ARM64 machines #7432
Merged
Conversation
This file contains 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
|
CC: @seungha-yang |
nirbheek
force-pushed
the
nirbheek/fix-native-windows-arm64-builds
branch
from
afc7d8d to
ab56319
Compare
I made the mistake of always selecting the debug CRT for compiler checks on Windows 4 years ago: #543 #614 The idea was to always build the tests with debugging enabled so that the compiler doesn't optimize the tests away. But we stopped doing that a while ago, and also the debug CRT has no relation to that. We should select the CRT in the same way that we do for building targets: based on the options. On Windows ARM64, the debug CRT for ARM64 isn't always available, and the release CRT is available only after installing the runtime package. Without this, we will always try to pick the debug CRT even when --buildtype=debugoptimized or release.
nirbheek
force-pushed
the
nirbheek/fix-native-windows-arm64-builds
branch
from
ab56319 to
9727bdc
Compare
vc2017x64vs and vc2019x64vs sometimes timeout because they exceed the 60 min default limit.
nirbheek
added a commit
to nirbheek/meson
that referenced
this pull request
Aug 25, 2020
This type happened in mesonbuild#7432 and wasn't noticed because I didn't add a test for it. Rectified now. If we don't specify the CRT, MSVC will pick /MT by default (!?) and link to `libcmt.lib`. This actually *breaks* UWP because `libcmt.lib` is not available by default when building for UWP. Was noticed here: cisco/libsrtp#505
nirbheek
added a commit
to nirbheek/meson
that referenced
this pull request
Aug 25, 2020
This type happened in mesonbuild#7432 and wasn't noticed because I didn't add a test for it. Rectified now. If we don't specify the CRT, MSVC will pick /MT by default (!?) and link to `libcmt.lib`. This actually *breaks* UWP because `libcmt.lib` is not available by default when building for UWP. Was noticed here: cisco/libsrtp#505
nirbheek
added a commit
that referenced
this pull request
Aug 27, 2020
This type happened in #7432 and wasn't noticed because I didn't add a test for it. Rectified now. If we don't specify the CRT, MSVC will pick /MT by default (!?) and link to `libcmt.lib`. This actually *breaks* UWP because `libcmt.lib` is not available by default when building for UWP. Was noticed here: cisco/libsrtp#505
nirbheek
added a commit
that referenced
this pull request
Sep 9, 2020
This type happened in #7432 and wasn't noticed because I didn't add a test for it. Rectified now. If we don't specify the CRT, MSVC will pick /MT by default (!?) and link to `libcmt.lib`. This actually *breaks* UWP because `libcmt.lib` is not available by default when building for UWP. Was noticed here: cisco/libsrtp#505
# for free
to join this conversation on GitHub.
Already have an account?
# 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.
I made the mistake of always selecting the debug CRT for compiler checks on Windows 4 years ago: #543 #614
The idea was to always build the tests with debugging enabled so that the compiler doesn't optimize the tests away. But we stopped doing that a while ago, and also the debug CRT has no relation to that.
We should select the CRT in the same way that we do for building targets: based on the options.
On Windows ARM64, the debug CRT for ARM64 isn't always available, and the release CRT is available only after installing the runtime package. Without this, we will always try to pick the debug CRT even when --buildtype=debugoptimized or release.