You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 😅
// 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:
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-rsalready tracks if it's clang_cl but doesn't currently expose that publicly, so we'll have to add that first.
Thanks!
The text was updated successfully, but these errors were encountered:
In `ring` we need to check if the compiler is `clang-cl`
to prevent overwriting it with `clang` (see all details in
briansmith/ring#2215), but `cc-rs` does not
currently expose this despite already tracking it. By adding this
getter we can steer that logic to not overwrite the compiler when it
is `clang-cl`.
Perhaps, since `ToolFamily` is `pub` (but not yet reexported from
`lib.rs`), could we have a public `Tool::family()` getter to not have
to extend these `is_xxx()` getters whenever a downstream crate wants to
know something new?
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:Problem statement
Unfortunately the Windows ARM64 support PR (#1339) overwrites the compiler with
clang
:ring/build.rs
Lines 549 to 556 in d2e401f
This code doesn't modify the flags, and leaves what my environment has in
CFLAGS_aarch64-pc-windows-msvc
in place. Without using theclang-cl
driver,clang
doesn't understand the above commands and compilingring
errors out with a bunch of errors like:Proposed solution
As mentioned at #1339 (comment)
clang-cl
works, albeit currently (on LLVM18.1.8
) with lots of warnings of the form: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'sclang_cl
but doesn't currently expose that publicly, so we'll have to add that first.Thanks!
The text was updated successfully, but these errors were encountered: