Repository navigation
under latest MinGW, cannot link with C code using stdout #47048
Description
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.
say_hi.c:
#include <stdio.h>
void say_hi(void) {
fprintf(stdout, "hi!\n");
}c_main.c
void say_hi(void);
int main(void) {
say_hi();
return 0;
}r_main.rs:
extern "C" {
fn say_hi();
}
fn main() {
unsafe {
say_hi();
}
}Under the latest MinGW, specifically with packages
mingw-w64-x86_64-crt-git-6.0.0.5066.61efe559-1andmingw-w64-x86_64-headers-git-6.0.0.5066.61efe559-1,
using only gcc like this works:
$ gcc -c say_hi.c
$ ar cr libsay_hi.a say_hi.o
$ gcc c_main.c -L. -lsay_hi -o c_main.exe && ./c_main.exe
hi!
But it doesn't work with rustc:
$ gcc -c say_hi.c
$ ar cr libsay_hi.a say_hi.o
$ rustc r_main.rs -L. -lsay_hi -o r_main.exe && ./r_main.exe
error: linking with `gcc` failed: exit code: 1
|
= note: "gcc" "-Wl,--enable-long-section-names" "-fno-use-linker-plugin" "-Wl,--nxcompat" "-nostdlib" "-m64" "C:\\Users\\Trevor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\crt2.o" "C:\\Users\\Trevor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\rsbegin.o" "-L" "C:\\Users\\Trevor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib" "r_main.r_main0.rust-cgu.o" "-o" "r_main.exe" "r_main.crate.allocator.rust-cgu.o" "-Wl,--gc-sections" "-nodefaultlibs" "-L" "." "-L" "C:\\Users\\Trevor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib" "-l" "say_hi" "-Wl,-Bstatic" "C:\\Users\\Trevor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libstd-60d4a252bdda9250.rlib" "C:\\Users\\Trevor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\liballoc_system-a05404e5e059417a.rlib" "C:\\Users\\Trevor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\librand-81cbf6f1d5a19206.rlib" "C:\\Users\\Trevor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libpanic_unwind-0b63e20460046692.rlib" "C:\\Users\\Trevor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\liballoc-f824a78e715239af.rlib" "C:\\Users\\Trevor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libstd_unicode-2abaea46f194a6e1.rlib" "C:\\Users\\Trevor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libunwind-7daa32005d584d8a.rlib" "C:\\Users\\Trevor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\liblibc-49ff25caaa6e945f.rlib" "C:\\Users\\Trevor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libcore-f2bd2d524c6ace24.rlib" "C:\\Users\\Trevor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libcompiler_builtins-c6139fac5e899293.rlib" "-Wl,-Bdynamic" "-l" "advapi32" "-l" "ws2_32" "-l" "userenv" "-l" "shell32" "-Wl,-Bstatic" "-l" "gcc_eh" "-l" "pthread" "-Wl,-Bdynamic" "-lmingwex" "-lmingw32" "-lgcc" "-lmsvcrt" "-luser32" "-lkernel32" "C:\\Users\\Trevor\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\rsend.o"
= note: ./libsay_hi.a(say_hi.o):say_hi.c:(.text+0x10): undefined reference to `__imp___acrt_iob_func'
error: aborting due to previous error
If I downgrade those two packages to
mingw-w64-x86_64-crt-git-5.0.0.5002.34a7c1c0-1andmingw-w64-x86_64-headers-git-5.0.0.5002.34a7c1c0-1,
it works with rustc too:
$ gcc -c say_hi.c
$ ar cr libsay_hi.a say_hi.o
$ rustc r_main.rs -L. -lsay_hi -o r_main.exe && ./r_main.exe
hi!
One last thing, if I compile the library using the old packages, and then upgrade the packages, both gcc c_main.c ... and rustc r_main.rs ... work. If I compile the library using the new packages, and then downgrade the packages, both gcc c_main.c ... and rustc r_main.rs ... fail.
Reacted by Kornel, Daniel Thiem, Borhan Hafez, Mateusz Mikuła, Cokemonkey11, Cameron Taggart, Shawn Walker-Salas, Jonas Schievink, Nicolai Großer, Tanish Sharma and 2 more
Activity
mati865 commentedon Dec 29, 2017
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.
cretz commentedon Feb 4, 2018
Got anyone else arriving here across the web w/ new MinGW breaks, in addition to:
You might also need to downgrade winpthreads (granted your version numbers may be different):
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.
tspiteri commentedon Feb 5, 2018
The old packages are also available at http://repo.msys2.org/mingw/x86_64/, where you can download the latest versions of the packages in question that include
git-5.0.0in their version rather than the new incompatiblegit-6.0.0. This could be required for example on a new MinGW installation where there are nogit-5.0.0packages in/var/cache/pacman/pkg.lins05 commentedon Feb 9, 2018
Reached here by googling.
@cretz thanks for the tip, it works
mati865 commentedon Mar 4, 2018
Should be fixed with
crt/headerspackages in version 6.0.0.5114.b9400293. They are already available in the repository.tspiteri commentedon Mar 5, 2018
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.*.)
mati865 commentedon Mar 5, 2018
Similar issue was fixed recently https://github.com/Alexpux/MINGW-packages/issues/3469.
Maybe rust internals have to be recompiled.
NovemberZulu commentedon Mar 31, 2018
Still happens for with
rustc 1.25.0(package in question iscargo-update). May be Rust build machine has older MinGW?mati865 commentedon Mar 31, 2018
Yeah, I just forgot that Rust is using
mingw-w64-buildstoolchain which is still based on 5.x mingw-w64 releases.That basically makes official Rust unusable within MSYS2.
NovemberZulu commentedon Mar 31, 2018
The build instructions for for windows-gnu specifically suggest using MSYS2 :( . Could you please elaborate a bit about that
mingw-w64-buildstoolchain?mati865 commentedon Mar 31, 2018
Bundling
/mingw64/x86_64-w64-mingw32/lib/libcrtdll.afrom MSYS2 toolchain could help but somebody would have to test it properly.https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/
NovemberZulu commentedon Mar 31, 2018
I looked around the link, and it seems that master already has
__acrt_iob_func, but v5.x does not. I wasnot able to find any kind of roadmap or ETA for v6.x release.NovemberZulu commentedon Apr 1, 2018
I built current Rust master using MSYS2, as described in README, and now I am able to build
cargo-updatewithout tinkering with include files. May be switching the official builds to MSYS2 is an option?83 remaining items
Switch Windows CI builds from windows-gnu to windows-msvc.
Switch Windows CI builds from windows-gnu to windows-msvc.
Switch Windows CI builds from windows-gnu to windows-msvc.
Switch Windows CI builds from windows-gnu to windows-msvc.
Switch Windows CI builds from windows-gnu to windows-msvc.
Switch Windows CI builds from windows-gnu to windows-msvc.
Switch Windows CI builds from windows-gnu to windows-msvc.
Switch Windows CI builds from windows-gnu to windows-msvc.
bs2kbs2k commentedon Aug 8, 2020
I solved this issue by running
to downgrade those 3 packages on archlinux.
CICD: Build: Enable *-pc-windows-gnu builds again (with 'stable')
CICD: Build: Enable x86_64-pc-windows-gnu again
CICD: Build: Enable x86_64-pc-windows-gnu again
Shoeboxam commentedon Sep 2, 2021
I was running into this same issue on rust 1.54 while attempting to build @tspiteri's gmp-mpfr-sys crate. I was able to build within the windows-latest Github actions environment on 2021-8-3 thanks to this comment.
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:
mati865 commentedon Sep 2, 2021
#72999
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
PATH. If this doesn't automatically work then it's new bug and could be worked around withRUSTFLAGS=-C link-self-contained=no.Switch Windows CI builds from windows-gnu to windows-msvc.