Change:
toolchain: build command: error message: possible reason: bug? bug? 2 gcc issues?
I also have this issue. I'd bet the cause is the same as , the version of crt2.o included with the target isn't the same as the one installed by MSYS2. When I switched to using the compiler rather than the target of an compiler, it worked fine. Perhaps there's something different there?
Much simpler to just copy c:msys64mingw64x8664-w64-mingw32libcrt2.0 to c:Users%USER%.rustuptoolchainsnightly-x8664-pc-windows-msvclibrustlibx86_64-pc-windows-gnulib
As far as I can tell, this happens because target for toolchain is missing a dependency on component. So when rustc invokes for linking, it either cannot find the linker, or invokes whatever other version of is on the path.
even if component wil be installed it will ship incompatible libraries and cause build errors. To fix them user have to copy libs from their MinGW toolchain anyway, cc
compatible with what? The -gnu target is supposed to use the bits of mingw bundled with it, not mingw toolchain installed on your machine. You might be right if there were some C/C++ code linked into the project that gets compiled with a different version of mingw, but an empty Rust project wouldn't have any FFI code in it. Also, consider that x8664-pc-windows-gnu toolchain works just fine, and the only difference is that it does contain the component. Could dependency be to target?
toolchain not only picks headers from the system but also various other libs. Neither of them is guaranteed to be compatible with old crt libs shipped with Rust and it causes real issues like mentioned earlier.
As I said, I don't deny that it's possible to run into compatibility problems when external C/C++ is involved. However, I think it's still perfectly fair to expect target to work at least as well as the toolchain, i.e. to be able to compile a pure-Rust program.
It would probably be pretty easy to add dependencies to wire this up but I would be wary to do so. Linking with our MinGW target is extremly fiddly and any change tends to have rippling effects causing regressions. I don't really personally want to lead the charge to do this, and unless we have someone willing to help handle the fallout I would discourage a change to the distribution strategy.
Right now that target doesn't work at all, how could it get worse?
At least in my experience it tends to not be that cut and dry, but again I'm not against doing this I just do not personally want to lead the charge to do so. Someone else is always more than welcome to do so.
I'm having the same (or similar) issue when cross-compiling from Linux to Windows: I'm on ArchLinux and followed the cross-compilation guide from
modify labels: -O-windows +O-windows-gnu you can use workaround from but change paths for Linux.
Could you link to the exact comment which has the work around? And what exactly needs to be changed for cross compiling from Linux? I can't seem to figure it out.
but for me copying the libs is enough (, and ). For i686 most distributions provide SJLJ based toolchain so you will have to get toolchain with DWARF2 or set in
Probably a duplicate of
Getting this trying to cross-compile from current Arch packages. Tried but it doesn't seem to fix the issue. What needs to change for this to work out of the box for people? I did take a look at the workaround, but I'm not running on Windows. So I don't have a C: apart from wine :). And I won't get to running this until I can build it.
for this issue the workaround is copying libs like I said 2 comments above. is for i686 toolchain only because Rust is using Dwarf exception handling but Linux distributions mostly ship i686 with SJLJ exceptions.
These have to be copied from mingw installed on Windows though.
No, you can use mingw from AUR. See the Arch wiki:
crt2.o and dllcrt2.o have to be copied over.

Discussion:
} } <ins> // Because windows-gnu target is meant to be self-contained for pure Rust code it bundles // own mingw-w64 libraries. These libraries are usually not compatible with mingw-w64 // installed in the system. This breaks many cases where Rust is mixed with other languages // (e.g. *-sys crates). // We prefer system mingw-w64 libraries if they are available to avoid this issue. fn get_crt_libs_path(sess: &Session) -> Option<PathBuf> { fn find_exe_in_path<P>(exe_name: P) -> Option<PathBuf> where P: AsRef<Path>, { for dir in env::split_paths(&env::var_os("PATH")?) { let full_path = dir.join(&exe_name); if full_path.is_file() { return Some(fix_windows_verbatim_for_gcc(&full_path)); } } None } fn probe(sess: &Session) -> Option<PathBuf> { if let (linker, LinkerFlavor::Gcc) = linker_and_flavor(&sess) { let linker_path = if cfg!(windows) && linker.extension().is_none() { linker.with_extension("exe") } else { linker }; if let Some(linker_path) = find_exe_in_path(linker_path) { let mingw_arch = match &sess.target.target.arch { x if x == "x86" => "i686", x => x, }; let mingw_dir = format!("{}-w64-mingw32", mingw_arch); // Here we have path/bin/gcc but we need path/ let mut path = linker_path; path.pop(); path.pop(); // Based on Clang MinGW driver let probe_path = path.join(&mingw_dir).join("lib"); if probe_path.exists() { return Some(probe_path); }; let probe_path = path.join(&mingw_dir).join("sys-root/mingw/lib"); if probe_path.exists() { return Some(probe_path); }; }; }; None } let mut system_library_path = sess.system_library_path.borrow_mut(); match &*system_library_path { Some(Some(compiler_libs_path)) => Some(compiler_libs_path.clone()), Some(None) => None, None => { let path = probe(sess); *system_library_path = Some(path.clone()); path } } } </ins> pub fn get_file_path(sess: &Session, name: &str) -> PathBuf { <ins> // prefer system {,dll}crt2.o libs, see get_crt_libs_path comment for more details if sess.target.target.llvm_target.contains("windows-gnu") { if let Some(compiler_libs_path) = get_crt_libs_path(sess) { let file_path = compiler_libs_path.join(name); if file_path.exists() { return file_path; } } } </ins> let fs = sess.target_filesearch(PathKind::Native); let file_path = fs.get_lib_path().join(name); if file_path.exists() {

// target descriptor let t = &sess.target.target; <ins> // prefer system mingw-w64 libs, see get_crt_libs_path comment for more details if cfg!(windows) && sess.target.target.llvm_target.contains("windows-gnu") { if let Some(compiler_libs_path) = get_crt_libs_path(sess) { cmd.include_path(&compiler_libs_path); } } </ins> cmd.include_path(&fix_windows_verbatim_for_gcc(&lib_path)); for obj in codegen_results.modules.iter().filter_map(|m| m.object.as_ref()) {

/// Mapping from ident span to path span for paths that don't exist as written, but that /// exist under `std`. For example, wrote `str::from_utf8` instead of `std::str::from_utf8`. pub confused_type_with_std_module: Lock<FxHashMap<Span, Span>>, <ins> /// Path for libraries that will take preference over libraries shipped by Rust. /// Used by windows-gnu targets to priortize system mingw-w64 libraries. pub system_library_path: OneThread<RefCell<Option<Option<PathBuf>>>>, </ins> } pub struct PerfStats {

driver_lint_caps, trait_methods_not_found: Lock::new(Default::default()), confused_type_with_std_module: Lock::new(Default::default()), <ins> system_library_path: OneThread::new(RefCell::new(Default::default())), </ins> }; validate_commandline_args_with_session_available(&sess);