briansmith
`aarch64-pc-windows-msvc` requires `clang`
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.
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 https://github.com/briansmith/ring/issues/1460#issuecomment-1830305112 and https://github.com/briansmith/ring/issues/1460#issuecomment-1830416384.
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.
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).
