Open Jasper-Bekkers opened 1 week ago
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 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.
Right now, as documented in
BUILDING.md
this library requiresclang
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: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).