aarch64-pc-windows-msvc requires clang

[Jasper-Bekkers]

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).

[briansmith]

It would be great if somebody could submit a PR.

[Jasper-Bekkers]

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.

[briansmith]

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.

[lilith]

This would be super helpful

[Gami13]

I'm getting compile errors even with clang installed

[lilith]

Same. This is currently my primary blocker for supporting windows.

[Jasper-Bekkers]

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).