Change:
I'm having an issue under MinGW and I'm not sure if it's a MinGW issue or a rustc issue. On the one hand the bug crops up after an update to two MinGW packages, but on the other hand I cannot reproduce with only C, and I don't know if rustc is using MinGW in some undocumented unsupported way. sayhi.c: cmain.c Under the latest MinGW, specifically with packages and , using only gcc like this works: But it doesn't work with rustc: If I downgrade those two packages to and , it works with rustc too: One last thing, if I compile the library using the old packages, and then upgrade the packages, both and work. If I compile the library using the new packages, and then downgrade the packages, both and fail.
Mingw-w64 seen some huge changes lately, if recompiling Rust with latest mingw-w64 doesn't work or still gives errors like that then it's probably a regression they introduced.
Got anyone else arriving here across the web w/ new MinGW breaks, in addition to: pacman -U /var/cache/pacman/pkg/mingw-w64-x8664-crt-git-5.0.0.4745.-1- pacman -U /var/cache/pacman/pkg/mingw-w64-x8664-headers-git-5.0.0.4747.-1- You might also need to downgrade winpthreads (granted your version numbers may be different): pacman -U /var/cache/pacman/pkg/mingw-w64-x8664-winpthreads-git-5.0.0.4741.-1- /var/cache/pacman/pkg/mingw-w64-x8664-libwinpthread-git-5.0.0.4741.-1- Had to do both at once due to codeps. I ran into this Rust+MinGW issue when statically building latest Tor and deps w/ latest MinGW.
The old packages are also available at , where you can download the latest versions of the packages in question that include in their version rather than the new incompatible . This could be required for example on a new MinGW installation where there are no packages in .
Reached here by googling. thanks for the tip, it works
Should be fixed with / packages in version 6.0.0.5114.. They are already available in the repository.
I upgraded to version 6.0.0.5114 and reproduced the issue. Downgrading to 5.0.0.5002 still works. (Keep in mind that if the library is built using 5.0.0.5002, linking will work using 6.0.0.*.)
Similar issue was fixed recently Maybe rust internals have to be recompiled.
Still happens for with (package in question is ). May be Rust build machine has older MinGW?
Yeah, I just forgot that Rust is using toolchain which is still based on 5.x mingw-w64 releases. That basically makes official Rust unusable within MSYS2.
The build instructions for for windows-gnu specifically suggest using MSYS2 :( . Could you please elaborate a bit about that toolchain?
Bundling from MSYS2 toolchain could help but somebody would have to test it properly.
I looked around the link, and it seems that master already has , but v5.x does not. I wasnot able to find any kind of roadmap or ETA for v6.x release.
I built current Rust master using MSYS2, as described in README, and now I am able to build without tinkering with include files. May be switching the official builds to MSYS2 is an option?
May be switching the official builds to MSYS2 is an option? What MSYS2 exactly? The mingw-w64 toolchain in MSYS2 is constantly updated and these updates regularly break something. That's why Rust uses a stable predictable standalone version from Mingw-builds. I'd personally recommend to do the same thing and use a standalone mingw toolchain instead of MSYS2 package (at least that's what I do). It may make sense to bump the version used by Rust from 6.3.0 to something up-to-date though.
What MSYS2 exactly? Some reasonably stable reasonably recent version :) I know this is self-contradictory. That's why Rust uses a stable predictable standalone version from Mingw-builds. I totally see the point, the issue is the build environment is not very well documented. Updating README with proper setup instructions for Windows GNU will help a lot.
Using toolchain with MSYS2 is not perfect either. If you want to use libs from MSYS2 with different toolchain you can also run into this error, like .
This build script can work around the issue. It is a bit hacky; basically it tests for the bug using this issue's test case, and if it detects the bug it creates and links libworkaround47048.a which contains the symbol as defined in newer MinGW, which is apparently not included when linking using rustc. This only works around the original issue, and does not handle the further issues for winpthreads raised in
Recent mingw-w64 GCC 8.1.0 build contains so it can be hit by this issue as well.
I'm not sure who is responsible for Windows GNU, I assume libs from are necessary for people who don't have GCC in their PATH. However they are an issue for people with GCC/MinGW versions different from Rust ones. They are built in specific environment and the fact they work in (some) other environments is just a coincidence that shouldn't be relied upon. Yet Windows GNU target prioritises them over host libraries and relies on host headers causing conflicts like impacrtiob_func'from this issue. It can be solved by: using host libraries over bundled if they exists bundling headers (66 MiB) and using them instead of host
Rustup does not currently offer a way to opt out of the bundled MinGW, but there is a way to work around that. If you use the toolchain and add the you will be able to cross compile to without any bundled MinGW and instead relying entirely on your locally installed MinGW.
, Can you elaborate on how you would go about avoiding the built-in MinGW, using the locally installed MinGW? I'm trying to construct an AppVeyor configuration that will build, avoiding this type of stdio incompatibility bug.
this is my work around
After looking at AppVeyor configurations by and , I spent some time constructing a relatively generic AppVeyor CI configuration which includes a workaround to allow compilation / testing with the "gnu" ABI. I've included the config file ([]()) in a PR for uutils/coreutils (uutils/coreutils). I think it's generic enough that it could be useful in other rust repos with only minor modifications. This is also a workaround for . ref:
Tomorrow Rust 2018 goes live, but the beta version still has problem with latest MinGW. The only fix that worked for me was from here: Will it be fixed so that the latest just work without wasting hours on finding workarounds? Msvc version works ok, but CLion supports debugging only with target and debugging is quite useful feature, you know... The linked solution feels very hacky and even if that works for now I feel uncomfortable with just replacing some files which I have no idea what are used for. Could someone at least confirm that that should work OK without unexpected problems down the road or propose a different solution that works with debugger?
yes it works for now (in the future probably more libs will require replacing). Rust is packaging old libraries that aren't compatible with headers from your system (that's why replacing libs does fix it).
I'm from the installed MinGW system to the rust area in the above []() config for AppVeyor testing. It works now and should act as a canary if a conflict arises. I'm doing the same thing as a local workaround with every update... It would be great to have at least an official mention of the workaround until a fix is implemented. cc: ,
I have try your method, such as . But it seems that rust use instead of , and it use msvc linker's flag: This makes the build failed. Are there any solutions?
Well, the downside of my method is that you're cross compiling from and so you need to actually have VC++ installed to link build scripts...
Well, it seems that it still get undefined reference... I have install VC++ build tools, but why shouldn't I directly use msvc toolchain to compile it instead of cross compile?:joy:
Founded a hacky way to solve this problem. Original solution from edit replace to , and then execute . add the following tocopy and from to Now it's OK. But you should do the above steps again once you use successfully.
Easiest workaround is to just copy and from to every time you update.
Thanks I overwritten all *.o files in the gnu toolchain with corresponding files from Msys2 and all linking problems gone!
After update to 1.34, I have try your solution, but it still can't work. Finally do the things again and it works.
modify labels: -O-windows +O-windows-gnu
Easiest workaround is to just copy crt2.o and dllcrt2.o from C:msys64mingw64x8664-w64-mingw32lib to ~.rustuptoolchainsstable-x8664-pc-windows-gnulibrustlibx8664-pc-windows-gnulib every time you update. I upgraded to / today and this did not_ solve the issue. I receive the following error when linking the code in the original post: I copied the libraries just fine it seems: The C link demonstrated in the original post works fine: GCC version is 7.3.0: And here is my : Am I missing something obvious to get Rust working again?
It's still not fixed and this workaround is recommend.
It's still not fixed and this workaround is recommend. But the workaround did not work. Even after I copied the relevant libraries, I still get the impacrtiob_func' error, among others. The information in my previous message is to try to isolate why the workaround didn't work. Anyways, I'm fully upgrading my msys2 distribution to see if this helps.
It could mean you have to copy more libs like , when using not latest mingw-w64 or there is discrepancy between your crt and it's headers.
~I have fully upgraded my MSYS2 installation. I have copied over and to Rust's directory and the problem still remains.~ ~What further steps should I take? E.g. where is and I can copy to the Rust directory?~ EDIT: Oops, I forgot to do , sorry! Just for my own curiosity, why is this step required?
EDIT: Oops, I forgot to do rustup component remove rust-mingw, sorry! Just for my own curiosity, why is this step required? Because the mingw bits in that component are a different version than the mingw used to compile the c code you're linking to and therefore incompatible. You don't actually need to copy over anything if you just remove that mingw component, and rely on your own external mingw.
Probably a duplicate of
this issue was opened earlier so is the duplicate.
Enjoy
& this workaround is not compiling for me. It gives the following 2 warnings and 2 errors: Updating from gcc 5.4.0 to gcc 7.4.0 did not fix this (on MinGW 64 bit, Windows 7). EDIT: The issue was with how I started MSYS2. I don't know precisely what I did wrong (I was messing with the that launches MSYS2), but it's working now that I use the stock batch script with arguments (I had to add that argument to get cargo working).
Hi Daniel , I tried your solution, but unfortunately I'm getting this error: What am I doing wrong? Any idea of how can I solve this? Thanks in advance.
Nominating since this affects quite a few users of a tier 1 platform and requires weird and potentially fragile workarounds.
visiting for triage. We spoke briefly about this . In that conversation, asked whether this was a correct summary of the situation (its drawn largely from from mingw issues breaking changes we are pinned to some older version right now it's perhaps not so well documented which version that is and newer versions are breaking So the questions are: What do we actually claim to support? Some fixed set of stand alone versions from mingw-builds? Or do we claim to support (the constantly updated) mingw-w64 toolchain in MSYS2? Separate question: Should we update our CI's build environment to use a more recent version? GIven the points above, is this actually a T-compiler issue at all? Or is it a T-infra one?
triage: P-high. Leaving nomination label, with hopes of discussing with T-compiler team the summary above, and take temperature as to whether this should be reclassified as a T-infra bug.
It sounds like this (and similar) issue could be fixed by doing what's proposed in (unless I misunderstand the root cause of these bugs)
Rust ships mingw-w64 libraries but not the headers. So it relies on mingw-w64 headers installed in the system and uses them together with old mingw-w64 libs shipped by component. This is asking for the troubles because headers version have to match libs version. GCC 6.3.0 revision 2 provided by mingw-builds, that means mingw-w64 5.0. Older mingw-w64 versions happen to work but there are no guarantees due to mentioned earlier headers vs libs versions mismatch. Newer mingw-w64 versions don't work at all. MSYS2 packages master branch of mingw-w64 and updates it often. I doubt Rust could support it. This has proven to not be that easy, previous attempt failed because newer GCC required more memory: mingw-builds stopped providing new versions but it's not that hard to build it. It's exactly the same issue. Proposition 1 is already done, proposition 2 is not going to fix it out of the box. I believe or is the only real solution. MinGW libs shipped by Rust should be last resort used only when there is no other C compiler installed.
Regarding previous discussion there is another argument for updating mingw-w64 version: I'm able to build Rust+LLVM with Clang (it's already done for Linux and MSVC) by passing few flags. It passes all the tests (modulo debuginfo for unrelated reasons) but the thing that holds me back from opening a PR is too old mingw-w64 version installed on Rust's CI. How this can be pushed forward since mingw-builds doesn't prepare new builds any more?
You've mentioned here and that this issue can be resolved by replacing rust-provided libraries with their distribution-provided counterparts. Can swapping libraries like this cause problems for the other precompiled dlls (e.g. , , etc) shipped with rust if upstream mingw libraries diverge too much from the version shipped with rust? Is this a stable workaround?
if only import and static libraries are replaced it won't break precompiled dlls. Shared libraries non available in the system that are required by Rust libs are still provided in directory. It can cause different issues like even without using any workarounds and eventually they should be removed but fixing import and static libraries is more important. Personally I had removed component and run these 2 commands every toolchain update since I have proper mingw toolchain in my PATH. I haven't had issues with that workaround so far.
for those watching, this issue was discussed at the T-compiler meeting . We that should move forward with their experimentation with fixes.
I solved this issue by running to downgrade those 3 packages on archlinux.
I was running into this same issue on rust 1.54 while attempting to build gmp-mpfr-sys crate. I was able to build within the windows-latest Github actions environment on 2021-8-3 The build was failing again when I cut the next release on 2021-8-31. I resolved it by adjusting the command to: This raises two questions: caused the change to the path? understand this issue has been closed by , but rust is still unable to find the relevant binaries. What change do I need to make to the system so that rust can find these binaries on its own?
This is the first report I see since this issue was closed. There should be no change required as long as the compiler is available in . If this doesn't automatically work then it's new bug and could be worked around with .

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);