-
Notifications
You must be signed in to change notification settings - Fork 169
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
Fix windows build and update BoringSSL to 2587c4974dbe9872451151c8e975f58567a1ce0d #279
Conversation
@gregcotten To ensure that we've actually squashed this series of bugs, would you be willing to also test this on your end? I've done some x86 Windows validation locally but I don't have an arm64 install of Windows floating about, and it sounds like you do. |
Using
I've attached the diagnostic c file and shell script, if that's relevant to you. |
Yeah, not relevant to this PR but not good: we shouldn't be able to crash clang, and having the release build be impossible to do is pretty bad. |
I'm chasing this crash with the LLVM folks. In the meantime, given the evidence that this doesn't regress |
This patch updates the BoringSSL vendoring pattern and updates BoringSSL itself to 2587c4974dbe9872451151c8e975f58567a1ce0d.
The changes to vendored assembly mean that we're in the inverted pattern from where we were before: we now have arm64 assembly, but not x86 assembly. This patch comments out the x86 assembly support on Windows. I've reached out to the BoringSSL team to work out if there is any interest on their end in ceasing the use of nasm on Windows, as SwiftPM can't use it today. For now, however, this is the pragmatic compromise.
Resolves #275.