under latest MinGW, cannot link with C code using stdout

[tspiteri]

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-1 and
• mingw-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-1 and
• mingw-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.

[mati865]

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]

Got anyone else arriving here across the web w/ new MinGW breaks, in addition to:

pacman -U /var/cache/pacman/pkg/mingw-w64-x86_64-crt-git-5.0.0.4745.d2384c2-1-any.pkg.tar.xz
pacman -U /var/cache/pacman/pkg/mingw-w64-x86_64-headers-git-5.0.0.4747.0f8f626-1-any.pkg.tar.xz

You might also need to downgrade winpthreads (granted your version numbers may be different):

pacman -U /var/cache/pacman/pkg/mingw-w64-x86_64-winpthreads-git-5.0.0.4741.2c8939a-1-any.pkg.tar.xz /var/cache/pacman/pkg/mingw-w64-x86_64-libwinpthread-git-5.0.0.4741.2c8939a-1-any.pkg.tar.xz

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]

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.0 in their version rather than the new incompatible git-6.0.0. This could be required for example on a new MinGW installation where there are no git-5.0.0 packages in /var/cache/pacman/pkg.

[lins05]

Reached here by googling.

@cretz thanks for the tip, it works

[mati865]

Should be fixed with crt/headers packages in version 6.0.0.5114.b9400293. They are already available in the repository.

[tspiteri]

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]

Similar issue was fixed recently https://github.com/Alexpux/MINGW-packages/issues/3469.

Maybe rust internals have to be recompiled.

[NovemberZulu]

Still happens for with rustc 1.25.0 (package in question is cargo-update). May be Rust build machine has older MinGW?

[mati865]

Yeah, I just forgot that Rust is using mingw-w64-builds toolchain which is still based on 5.x mingw-w64 releases.
That basically makes official Rust unusable within MSYS2.

[NovemberZulu]

The build instructions for for windows-gnu specifically suggest using MSYS2 :( . Could you please elaborate a bit about that mingw-w64-builds toolchain?

[mati865]

Bundling /mingw64/x86_64-w64-mingw32/lib/libcrtdll.a from MSYS2 toolchain could help but somebody would have to test it properly.

Could you please elaborate a bit about that mingw-w64-builds toolchain?

https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/

[NovemberZulu]

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]

I built current Rust master using MSYS2, as described in README, and now I am able to build cargo-update without tinkering with include files. May be switching the official builds to MSYS2 is an option?

[petrochenkov]

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.

[NovemberZulu]

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.

[mati865]

Using mingw-builds 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 here.

[tspiteri]

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 libworkaround_47048.a which contains the __imp___acrt_iob_func 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 #47048 (comment).

use std::env;
use std::fs::{self, File};
use std::io::Write;
use std::path::{Path, PathBuf};
use std::process::Command;

fn main() {
    let target = env::var_os("TARGET")
        .expect("TARGET")
        .into_string()
        .expect("TARGET");
    if target.contains("-windows-gnu") {
        mingw_check_47048();
    }
}

fn mingw_check_47048() {
    let rustc = env::var_os("RUSTC").expect("RUSTC");
    let out_dir = PathBuf::from(env::var_os("OUT_DIR").expect("OUT_DIR"));
    let try_dir = out_dir.join("try_47048");
    let mut cmd;

    fs::create_dir_all(&try_dir).expect("create directory");
    create_file(&try_dir.join("say_hi.c"), SAY_HI_C);
    create_file(&try_dir.join("c_main.c"), C_MAIN_C);
    create_file(&try_dir.join("r_main.rs"), R_MAIN_RS);
    create_file(&try_dir.join("workaround.c"), WORKAROUND_C);

    cmd = Command::new("gcc");
    cmd.current_dir(&try_dir).args(&["-fPIC", "-c", "say_hi.c"]);
    execute(cmd);

    cmd = Command::new("ar");
    cmd.current_dir(&try_dir)
        .args(&["cr", "libsay_hi.a", "say_hi.o"]);
    execute(cmd);

    cmd = Command::new("gcc");
    cmd.current_dir(&try_dir)
        .args(&["c_main.c", "-L.", "-lsay_hi", "-o", "c_main.exe"]);
    execute(cmd);

    // try simple rustc command that should work, so that failure
    // really is the bug being checked for
    cmd = Command::new(&rustc);
    cmd.arg("--version");
    execute(cmd);

    cmd = Command::new(&rustc);
    cmd.current_dir(&try_dir)
        .args(&["r_main.rs", "-L.", "-lsay_hi", "-o", "r_main.exe"]);
    let status = cmd
        .status()
        .unwrap_or_else(|_| panic!("Unable to execute: {:?}", cmd));
    let need_workaround = !status.success();

    // build and test libworkaround_47048.a
    if need_workaround {
        cmd = Command::new("gcc");
        cmd.current_dir(&try_dir).args(&["-fPIC", "-O2", "-c", "workaround.c"]);
        execute(cmd);

        cmd = Command::new("ar");
        cmd.current_dir(&try_dir)
            .args(&["cr", "libworkaround_47048.a", "workaround.o"]);
        execute(cmd);

        cmd = Command::new(&rustc);
        cmd.current_dir(&try_dir).args(&[
            "r_main.rs",
            "-L.",
            "-lsay_hi",
            "-lworkaround_47048",
            "-o",
            "r_main.exe",
        ]);
        execute(cmd);

        let src = try_dir.join("libworkaround_47048.a");
        let lib_dir = out_dir.join("lib");
        fs::create_dir_all(&lib_dir).expect("create directory");
        let dst = lib_dir.join("libworkaround_47048.a");
        fs::rename(src, dst).expect("move file");

        let lib_dir_str = lib_dir.to_str().expect("unsupported characters");
        println!("cargo:rustc-link-search=native={}", lib_dir_str);
        println!("cargo:rustc-link-lib=static=workaround_47048");
    }

    fs::remove_dir_all(try_dir).expect("remove directory");
}

fn create_file(filename: &Path, contents: &str) {
    let mut file = File::create(filename)
        .unwrap_or_else(|_| panic!("Unable to create file: {:?}", filename));
    file.write_all(contents.as_bytes())
        .unwrap_or_else(|_| panic!("Unable to write to file: {:?}", filename));
}

fn execute(mut command: Command) {
    let status = command
        .status()
        .unwrap_or_else(|_| panic!("Unable to execute: {:?}", command));
    if !status.success() {
        if let Some(code) = status.code() {
            panic!("Program failed with code {}: {:?}", code, command);
        } else {
            panic!("Program failed: {:?}", command);
        }
    }
}

const SAY_HI_C: &'static str = r#"/* say_hi.c */
#include <stdio.h>
void say_hi(void) {
    fprintf(stdout, "hi!\n");
}
"#;

const C_MAIN_C: &'static str = r#"/* c_main.c */
void say_hi(void);
int main(void) {
    say_hi();
    return 0;
}
"#;

const R_MAIN_RS: &'static str = r#"// r_main.rs
extern "C" {
    fn say_hi();
}
fn main() {
    unsafe {
        say_hi();
    }
}
"#;

const WORKAROUND_C: &'static str = r#"/* workaround.c */
#define _CRTBLD
#include <stdio.h>

FILE *__cdecl __acrt_iob_func(unsigned index)
{
    return &(__iob_func()[index]);
}

typedef FILE *__cdecl (*_f__acrt_iob_func)(unsigned index);
_f__acrt_iob_func __MINGW_IMP_SYMBOL(__acrt_iob_func) = __acrt_iob_func;
"#;

[mati865]

Recent mingw-w64 GCC 8.1.0 build contains __acrt_iob_func so it can be hit by this issue as well.

[bs2kbs2k]

I solved this issue by running

pacman -U https://archive.org/download/archlinux_pkg_mingw-w64-crt/mingw-w64-crt-5.0.0-1-any.pkg.tar.xz https://archive.org/download/archlinux_pkg_mingw-w64-headers/mingw-w64-headers-5.0.0-1-any.pkg.tar.xz https://archive.org/download/archlinux_pkg_mingw-w64-winpthreads/mingw-w64-winpthreads-5.0.0-1-any.pkg.tar.xz

to downgrade those 3 packages on archlinux.

[Shoeboxam]

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:

cp -f /mingw64/x86_64-w64-mingw32/lib/{*.a,*.o} `rustc --print sysroot`/lib/rustlib/x86_64-pc-windows-gnu/lib/self-contained

This raises two questions:

1. What caused the change to the path?
2. I understand this issue has been closed by windows-gnu: prefer system crt libraries if they are available #67429, 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?

[mati865]

What caused the change to the path?

#72999

I understand this issue has been closed by windows-gnu: prefer system crt libraries if they are available #67429, 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 PATH. If this doesn't automatically work then it's new bug and could be worked around with RUSTFLAGS=-C link-self-contained=no.