`aarch64-pc-windows-msvc` requires `clang`
Jasper-Bekkers opened this issue · 8 comments
Right now, as documented in BUILDING.md this library requires clang in the path for this -msvc target which of course is quite unexpected.
This leads to a rather frustrating experience using this library: all crates using ring will exhibit downstream compilation errors, which goes counter to what's in the readme:
Particular attention is being paid to making it easy to build and integrate ring into applications and higher-level frameworks
I would suggest to provide pre-built binaries for this target alongside the x86 & x64_86 targets (though I have no idea how this would impact the size of the final .crate), or to make code build from source on -msvc targets (I expect this to be significantly more difficult).
It would be great if somebody could submit a PR.
It would be great if somebody could submit a PR.
I find the build setup for this crate quite convoluted to figure out from source (it needs perl & python in addition to Rust it seems)? If you have some pointers on where to look roughly I can try to take a stab at it. Even if it's just a dump of filenames & function calls to take a look at, it would help.
I find the build setup for this crate quite convoluted to figure out from source (it needs perl & python in addition to Rust it seems)? If you have some pointers on where to look roughly I can try to take a stab at it. Even if it's just a dump of filenames & function calls to take a look at, it would help.
When working on this crate from a Git checkout on Windows, I find it works best to work in a "Git Bash" or "MinGW" prompt. Then it needs nasm too. mk/install-build-tools.ps1 contains the git checkout that will give you the same nasm that is used in ring's CI (and BoringSSL's, incidentally).
I don't know what BoringSSL does for Aarch64 Windows. I would look into what its build system is doing.
build.rs is convoluted because of the pregeneration facility. Look at mk/package.sh to see how pregeneration before publishing is done. See also #1460 (comment) and #1460 (comment).
IIRC, the main reasons we require clang boiled down to:
-
Some code previously required 128-bit integer support. It looks like this may no longer be the case, because we have a p256-nistz support for Aarch64 now. So we might "just" need to
#if !defined(OPENSSL_WINDOWS)around the code in p256.c. -
The Aarch64 assembly code output from PerlAsm uses C preprocessing directives, whereas for x86/x86_64 PerlAsm has support for outputting nasm syntax. I have no idea about the Microsoft AArch64 assembler and what its needs or capabilities are. Also, historically, Visual Studio didn't ship a standalone assembler in every edition; for example on x86/x86_64, masm.exe was a separate download, IIRC. Not sure if that's changed or not. Regarding your idea for pre-assembling the assembly sources for Aarch64 Windows like we do x86/x86_64, I am open to doing that, if this ends up being the only issue.
This would be super helpful
I'm getting compile errors even with clang installed
Same. This is currently my primary blocker for supporting windows.
Unfortunately I didn't have time immediately since we're shipping a product atm so attention needed to be refocussed. I'd love to see this get picked up at some point tho (or get back to it myself).