Conflicting C(XX)FLAGS when cross-compiling to aarch64-pc-windows-msvc

[MarijnS95]

First of all thanks for landing #1339 in some crates.io release! Would be great if this repository had git tags to follow along where commits are reachable 😅

Setup

When cross-compiling (currently from a Linux setup) to Windows, it's common to use https://jake-shadle.github.io/xwin/ / https://github.com/Jake-Shadle/xwin to set up headers and libraries.

When running this in my home directory (/home/marijn):

$ xwin --arch x86_64,aarch64 --sdk-version 10.0.22621 splat

I add the following to my ~/.cargo/config.toml to support cross-compiling C(++) sources in our Rust tree, and ultimately linking a binary:

[target.aarch64-pc-windows-msvc]
linker = "lld-link"
rustflags = [
    "-Lnative=/home/marijn/.xwin-cache/splat/crt/lib/aarch64",
    "-Lnative=/home/marijn/.xwin-cache/splat/sdk/lib/um/aarch64",
    "-Lnative=/home/marijn/.xwin-cache/splat/sdk/lib/ucrt/aarch64",
]

[env]
CC_aarch64-pc-windows-msvc = "clang-cl"
CXX_aarch64-pc-windows-msvc = "clang-cl"
AR_aarch64-pc-windows-msvc = "llvm-lib"

CFLAGS_aarch64-pc-windows-msvc = "-Wno-unused-command-line-argument -fuse-ld=lld-link -vctoolsdir/home/marijn/.xwin-cache/splat/crt -winsdkdir/home/marijn/.xwin-cache/splat/sdk"
CXXFLAGS_aarch64-pc-windows-msvc = "-Wno-unused-command-line-argument -fuse-ld=lld-link -vctoolsdir/home/marijn/.xwin-cache/splat/crt -winsdkdir/home/marijn/.xwin-cache/splat/sdk"

Problem statement

Unfortunately the Windows ARM64 support PR (#1339) overwrites the compiler with clang:

ring/build.rs

Lines 549 to 556 in d2e401f

	let compiler = c.get_compiler();
	// FIXME: On Windows AArch64 we currently must use Clang to compile C code
	let compiler = if target.os == WINDOWS && target.arch == AARCH64 && !compiler.is_like_clang() {
	let _ = c.compiler("clang");
	c.get_compiler()
	} else {
	compiler
	};

This code doesn't modify the flags, and leaves what my environment has in CFLAGS_aarch64-pc-windows-msvc in place. Without using the clang-cl driver, clang doesn't understand the above commands and compiling ring errors out with a bunch of errors like:

warning: [email protected]: clang: error: unknown argument: '-vctoolsdir/home/marijn/.xwin-cache/splat/crt'
warning: [email protected]: clang: error: unknown argument: '-winsdkdir/home/marijn/.xwin-cache/splat/sdk'
warning: [email protected]: ToolExecError: Command "clang" "-O3" "--target=aarch64-pc-windows-msvc" "-ffunction-sections" "-fdata-sections" "-g" "-fno-omit-frame-pointer" "--target=aarch64-pc-windows-msvc" "-I" "ring/include" "-I" "myproject/target/aarch64-pc-windows-msvc/debug/build/ring-81f4360e84b9e6a3/out" "-Wno-unused-command-line-argument" "-fuse-ld=lld-link" "-vctoolsdir/home/marijn/.xwin-cache/splat/crt" "-winsdkdir/home/marijn/.xwin-cache/splat/sdk" "-fvisibility=hidden" "-std=c1x" "-Wall" "-Wbad-function-cast" "-Wcast-align" "-Wcast-qual" "-Wconversion" "-Wmissing-field-initializers" "-Wmissing-include-dirs" "-Wnested-externs" "-Wredundant-decls" "-Wshadow" "-Wsign-compare" "-Wsign-conversion" "-Wstrict-prototypes" "-Wundef" "-Wuninitialized" "-g3" "-Werror" "-o" "myproject/target/aarch64-pc-windows-msvc/debug/build/ring-81f4360e84b9e6a3/out/8551bf18c762c50d-curve25519.o" "-c" "ring/crypto/curve25519/curve25519.c" with args clang did not execute successfully (status code exit status: 1).

Proposed solution

As mentioned at #1339 (comment) clang-cl works, albeit currently (on LLVM 18.1.8) with lots of warnings of the form:

error: mixing declarations and code is incompatible with standards before C99 [-Werror,-Wdeclaration-after-statement]
error: unsafe buffer access [-Werror,-Wunsafe-buffer-usage]

I'd be happy to PR a change to not overwrite the compiler when it is clang-cl like, next to the existing ... && !compiler.is_clang_like(). cc-rs already tracks if it's clang_cl but doesn't currently expose that publicly, so we'll have to add that first.

Thanks!

[MarijnS95]

@briansmith these are the errors that show up when compiling with cl.exe from MSVC 14.41.34120 for aarch64-pc-windows-msvc (cross-compiled from x64 Windows host):

ring\crypto\fipsmodule\bn\internal.h(191): error C2065: 'BN_ULLONG': undeclared identifier
ring\crypto\fipsmodule\bn\internal.h(191): error C2146: syntax error: missing ';' before identifier 'result'
ring\crypto\fipsmodule\bn\internal.h(191): warning C4555: result of expression not used
ring\crypto\fipsmodule\bn\internal.h(191): error C2065: 'result': undeclared identifier
ring\crypto\fipsmodule\bn\internal.h(191): error C2065: 'BN_ULLONG': undeclared identifier
ring\crypto\fipsmodule\bn\internal.h(191): error C2146: syntax error: missing ';' before identifier 'a'
ring\crypto\fipsmodule\bn\internal.h(191): warning C4552: '*': result of expression not used
ring\crypto\fipsmodule\bn\internal.h(192): error C2065: 'result': undeclared identifier
ring\crypto\fipsmodule\bn\internal.h(193): error C2065: 'result': undeclared identifier
ring\crypto\fipsmodule\bn\internal.h(193): warning C4293: '>>': shift count negative or too big, undefined behavior
ring\crypto\fipsmodule\bn\../../limbs/limbs.inl(38): warning C4163: '_addcarry_u64': not available as an intrinsic function
ring\crypto\fipsmodule\bn\../../limbs/limbs.inl(38): warning C4163: '_subborrow_u64': not available as an intrinsic function
ring\crypto\fipsmodule\bn\../../limbs/limbs.inl(62): warning C4013: '_addcarry_u64' undefined; assuming extern returning int
ring\crypto\fipsmodule\bn\../../limbs/limbs.inl(62): warning C4242: '=': conversion from 'int' to 'Carry', possible loss of data
ring\crypto\fipsmodule\bn\../../limbs/limbs.inl(76): warning C4242: '=': conversion from 'int' to 'Carry', possible loss of data
ring\crypto\fipsmodule\bn\../../limbs/limbs.inl(92): warning C4013: '_subborrow_u64' undefined; assuming extern returning int
ring\crypto\fipsmodule\bn\../../limbs/limbs.inl(92): warning C4242: '=': conversion from 'int' to 'Carry', possible loss of data
ring\crypto\fipsmodule\bn\../../limbs/limbs.inl(106): warning C4242: '=': conversion from 'int' to 'Carry', possible loss of data

The first ones in internal.h are trivial, we have 3e65265 that documents that uint128_t isn't defined by MSVC, and this custom code that uses the missing typedef but doesn't have a fallback for non-x86 with MSVC:

ring/crypto/fipsmodule/bn/internal.h

Lines 186 to 195 in 0223acb

	static inline void bn_umult_lohi(BN_ULONG *low_out, BN_ULONG *high_out,
	BN_ULONG a, BN_ULONG b) {
	#if defined(OPENSSL_X86_64) && defined(_MSC_VER) && !defined(__clang__)
	*low_out = _umul128(a, b, high_out);
	#else
	BN_ULLONG result = (BN_ULLONG)a * b;
	*low_out = (BN_ULONG)result;
	*high_out = (BN_ULONG)(result >> BN_BITS2);
	#endif
	}

A fix for this is described here:
#1339 (comment)
https://github.com/google/boringssl/blob/47c5f9d2f6c294622baf07c3373de752fd518b03/crypto/fipsmodule/bn/internal.h#L418

---

The second _addcarry_u64 / _subborrow_u64 intrinsics are behind a #if defined(_MSC_VER) && !defined(__clang__) and probably need to check for the architecture. If they're not defined, a C implementation seems to be used. The #else case here however also uses uint128_t:

ring/crypto/limbs/limbs.inl

Lines 47 to 54 in 0223acb

	#else
	typedef Limb Carry;
	#if LIMB_BITS == 64
	typedef __uint128_t DoubleLimb;
	#elif LIMB_BITS == 32
	typedef uint64_t DoubleLimb;
	#endif
	#endif