Stop passing an invalid target to llvm-mingw's cross-compilation wrappers
#1495
Conversation
…appers The cross-compilation toolchains distributed by the `llvm-mingw` project for building code for the `*-pc-windows-gnullvm` targets have a wrapper script in place of their `clang` binaries that calls them with a specific target, much like it has been the case with the Android NDK. When `cc-rs` sets a explicit `--target` flag, the wrapper script breaks down, and is no longer able to use the proper linker and libraries. To improve on this situation and make it possible to cross-compile Rust projects that depend on building C code with `cc-rs`, let's skip passing this flag when cross-compilation with such a wrapper script is attempted.
| fn is_llvm_mingw_wrapper(clang_path: &Path) -> bool { | ||
| if let Some(filename) = clang_path | ||
| .file_name() | ||
| .and_then(|file_name| file_name.to_str()) |
There was a problem hiding this comment.
Is there a more robust way of testing?
I.e. checking version etc?
There was a problem hiding this comment.
Thanks for the review! I agree that a more robust detection method could be nice.
After taking a closer look at the llvm-mingw repository, it appears that this cross-compilation toolchain has setting a target since its very first tagged release, 20181017.
For Unix host platforms, the wrapper script has consistently been symlinked from x86_64-w64-mingw32-clang and similar names, so the toolchain has been quite consistent in this regard. As a result, checking its version doesn't seem necessary.
Interestingly, running x86_64-w64-mingw32-clang -v on any version of the toolchain reports the default target as x86_64-w64-windows-gnu. This doesn't exactly match either x86_64-pc-windows-gnu or x86_64-w64-mingw32, but it still seems to work just fine. (Why are LLVM's target names so inconsistent? 😅 I don't think I'd want to rely on the reported target for any important decisions on cc-rs...)
That said, aside from the target string oddities, this is a fairly standard LLVM toolchain with varying standard LLVM versions that aren't particularly distinct from stock LLVM. I don't think it's worth running any command with potentially brittle output or implement any extra complexity to determine whether to skip passing a target parameter in this case.
Instead, I figured we could check whether the compiler path is a symlink to a clang-target-wrapper.sh script. If and only if it is, we return true in this function. This approach should have a negligible chance of false positives, and in the unforeseen case that something goes wrong, users still have a fallback option other than fiddling with compiler flags: modifying the wrapper script directly.
What do you think?
The cross-compilation toolchains distributed by the
llvm-mingwproject for building code for the*-pc-windows-gnullvmtargets have a wrapper script in place of theirclangbinaries that calls them with a specific target, much like it has been the case with the Android NDK. Whencc-rssets a explicit--targetflag, the wrapper script breaks down, and is no longer able to use the proper linker and libraries.To improve on this situation and make it possible to cross-compile Rust projects that depend on building C code with
cc-rs, let's skip passing this flag when cross-compilation with such a wrapper script is attempted.