Can't cross compile from Linux to Windows (i686)

[bozaro]

Environment:

• Ubuntu 16.04 LTS final beta (lxc-create -n rust -t ubuntu -- --release xenial)
• Mingw (apt install mingw-w64)
• rustup tool (curl https://sh.rustup.rs -sSf | sh)
• Rust 1.8 and nightly (rustup default beta/rustup default nightly)
• Rust windows i686 toolchain (rustup target add i686-pc-windows-gnu)

I create a sample file hello.rs:

fn main() {
    println!("Hello, world!");
}

And run compilation:

rustc -v -C linker=i686-w64-mingw32-ld --target i686-pc-windows-gnu hello.rs

I expected hello.exe file, but has error:

error: linking with `i686-w64-mingw32-ld` failed: exit code: 1
note: "i686-w64-mingw32-ld" "-Wl,--enable-long-section-names" "-fno-use-linker-plugin" "-Wl,--nxcompat" "-nostdlib" "-Wl,--large-address-aware" "/home/ubuntu/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/i686-pc-windows-gnu/lib/crt2.o" "/home/ubuntu/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/i686-pc-windows-gnu/lib/rsbegin.o" "-L" "/home/ubuntu/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/i686-pc-windows-gnu/lib" "hello.0.o" "-o" "hello.exe" "-Wl,--gc-sections" "-nodefaultlibs" "-L" "/home/ubuntu/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/i686-pc-windows-gnu/lib" "-Wl,-Bstatic" "-Wl,-Bdynamic" "/home/ubuntu/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/i686-pc-windows-gnu/lib/libstd-18402db3.rlib" "/home/ubuntu/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/i686-pc-windows-gnu/lib/libcollections-18402db3.rlib" "/home/ubuntu/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/i686-pc-windows-gnu/lib/librustc_unicode-18402db3.rlib" "/home/ubuntu/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/i686-pc-windows-gnu/lib/librand-18402db3.rlib" "/home/ubuntu/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/i686-pc-windows-gnu/lib/liballoc-18402db3.rlib" "/home/ubuntu/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/i686-pc-windows-gnu/lib/liballoc_system-18402db3.rlib" "/home/ubuntu/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/i686-pc-windows-gnu/lib/liblibc-18402db3.rlib" "/home/ubuntu/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/i686-pc-windows-gnu/lib/libcore-18402db3.rlib" "-l" "gcc_eh" "-l" "gcc_eh" "-l" "ws2_32" "-l" "userenv" "-l" "shell32" "-l" "advapi32" "-l" "compiler-rt" "-lmingwex" "-lmingw32" "-lgcc" "-lmsvcrt" "-luser32" "-lkernel32" "/home/ubuntu/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/i686-pc-windows-gnu/lib/rsend.o"
note: i686-w64-mingw32-ld: unrecognized option '-Wl,--enable-long-section-names'
i686-w64-mingw32-ld: use the --help option for usage information

error: aborting due to previous error

[bozaro]

Same issue with Ubuntu 14.04.4 LTS

[alexcrichton]

Thanks for the report! Like with #32858 you'll want to pass gcc instead of ld, but unfortunately i686 probably won't work because the threading model of the compiler on Ubuntu is pthreads where we target the Windows threading model (an alternate mingw toolchain). As a result you'll probably still get link failures :(

[bozaro]

I try command:

rustc -v -C linker=i686-w64-mingw32-gcc --target x86_64-pc-windows-gnu hello.rs

But it don't work :(

error: linking with `i686-w64-mingw32-gcc` failed: exit code: 1
note: "i686-w64-mingw32-gcc" "-Wl,--enable-long-section-names" "-fno-use-linker-plugin" "-Wl,--nxcompat" "-nostdlib" "-Wl,--large-address-aware" "/home/ubuntu/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/i686-pc-windows-gnu/lib/crt2.o" "/home/ubuntu/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/i686-pc-windows-gnu/lib/rsbegin.o" "-L" "/home/ubuntu/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/i686-pc-windows-gnu/lib" "hello.0.o" "-o" "hello.exe" "-Wl,--gc-sections" "-nodefaultlibs" "-L" "/home/ubuntu/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/i686-pc-windows-gnu/lib" "-Wl,-Bstatic" "-Wl,-Bdynamic" "/home/ubuntu/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/i686-pc-windows-gnu/lib/libstd-18402db3.rlib" "/home/ubuntu/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/i686-pc-windows-gnu/lib/libcollections-18402db3.rlib" "/home/ubuntu/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/i686-pc-windows-gnu/lib/librustc_unicode-18402db3.rlib" "/home/ubuntu/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/i686-pc-windows-gnu/lib/librand-18402db3.rlib" "/home/ubuntu/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/i686-pc-windows-gnu/lib/liballoc-18402db3.rlib" "/home/ubuntu/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/i686-pc-windows-gnu/lib/liballoc_system-18402db3.rlib" "/home/ubuntu/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/i686-pc-windows-gnu/lib/liblibc-18402db3.rlib" "/home/ubuntu/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/i686-pc-windows-gnu/lib/libcore-18402db3.rlib" "-l" "gcc_eh" "-l" "gcc_eh" "-l" "ws2_32" "-l" "userenv" "-l" "shell32" "-l" "advapi32" "-l" "compiler-rt" "-lmingwex" "-lmingw32" "-lgcc" "-lmsvcrt" "-luser32" "-lkernel32" "/home/ubuntu/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/i686-pc-windows-gnu/lib/rsend.o"
note: /home/ubuntu/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/i686-pc-windows-gnu/lib/libstd-18402db3.rlib(std-18402db3.0.o):(.text+0xa9): undefined reference to `_Unwind_Resume'
/home/ubuntu/.multirust/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/i686-pc-windows-gnu/lib/libstd-18402db3.rlib(std-18402db3.0.o):(.text+0x1d163): undefined reference to `_Unwind_RaiseException'
collect2: error: ld returned 1 exit status

error: aborting due to previous error

[alexcrichton]

Yep that's the expected error! Those two symbols aren't defined in all mingw toolchains, but they're the ones that we want. I'm not entirely sure what the best course of action here is for this cross-compilation scenario...

cc @vadimcn

[vadimcn]

Yeah, these are symbols from the DWARF unwinder, which we use on Windows. For some reason Linux distros prefer to configure cross-mingw toolchain for SJLJ unwinding, so these symbols are missing.

As for what can be done...
I did a quick experiment and copied libgcc_eh.a that comes with Windows mingw-w64 toolchain into Rust's lib/rustlib/i686-pc-windows-gnu/lib directory on my Linux box, and was able to link a simple Rust program for the windows target. I suppose we could bundle libgcc_eh with the rust-std component, at least for -pc-windows-gnu targets.
However I am not entirely sure that it won't clash with the cross-mingw's own libgcc, especially if C/C++ libs are involved. I'd be much more comfortable if we could figure out a way to restrict the visibility of the dwarf unwinder symbols to libstd only.

[vadimcn]

... and was able to link a simple Rust program for the windows target

On second look, it didn't work out as well as I had thought: unwinding on panic! doesn't work. I guess the stack unwinding tables are getting registered with the wrong unwinder. Or something. :-(

Edit: nevermind, it did work after all :-)

[palazzo-train]

I got the same problem but i resolve it now. It seems the lib/rustlib/i686-pc-windows-gnu/lib from multirust is not the good one.

If I download the native windows package http://static.rust-lang.org/dist/2016-04-14/rust-nightly-i686-pc-windows-gnu.exe, (for rustc 1.9.0-nightly (2b60207 2016-04-13)) and install in windows, I get the lib\rustlib\i686-pc-windows-gnu\lib there.

You can find there are more files from windows lib then from linux multirust lib for i686-pc-windows-gnu. I copy . from windows lib to linux multirust lib. Then it works.

Perhaps multirust is not picking good source of files when it adds target? I don't know.

[alexcrichton]

Hm that may actually be because the rust-* package is an assembly of a bunch of components, namely the rust-mingw components. I think that rust-mingw actually has the right set of libraries, so now that you mention it that should work!

So basically if you install both the rust-std and rust-mingw package then cross-compilation should work out of the box (I think).

cc @brson, seems... an interesting insight! Also another reason to control components, we'd probably want to actually install the rust-mingw package by default on Linux perhaps?

[lunemec]

I'm experiencing the same issue on x86_64-pc-windows-gnu.

What I tried:

• compiling on macos
  • installing the windows-gnu toolchain
  • activating the toolchain as default
  • installing target platform windows-gnu for this toolchain
  • checked components for present rust-mingw (it is installed)
  • still got linker error.
• compiling inside docker on linux
  • same procedure - tried with both linux-gnu and windows-gnu toolchains
  • the same linker error.

Rustup show:

$ rustup show
Default host: x86_64-unknown-linux-gnu

installed toolchains
--------------------

stable-x86_64-pc-windows-gnu (default)
stable-x86_64-unknown-linux-gnu

active toolchain
----------------

stable-x86_64-pc-windows-gnu (default)
(rustc does not exist)

Target list:

$ rustup target list
x86_64-pc-windows-gnu (default)

Component list:

$ rustup component list
cargo-x86_64-pc-windows-gnu (default)
rust-docs-x86_64-pc-windows-gnu (default)
rust-mingw-x86_64-pc-windows-gnu (default)
rust-std-x86_64-pc-windows-gnu (default)
rustc-x86_64-pc-windows-gnu (default)

Error I got: (the error is the same if I use target stable)

$ rustup run x86_64-pc-windows-gnu cargo build --target=x86_64-pc-windows-gnu --release
   Compiling rust-birkana v0.1.1 (file:///home/developer)
error: linking with `gcc` failed: exit code: 1
  |
  = note: "gcc" "-Wl,--enable-long-section-names" "-fno-use-linker-plugin" "-Wl,--nxcompat" "-nostdlib" "-m64" "/home/developer/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/crt2.o" "/home/developer/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/rsbegin.o" "-L" "/home/developer/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib" "/home/developer/target/x86_64-pc-windows-gnu/release/rust_birkana.0.o" "-o" "/home/developer/target/x86_64-pc-windows-gnu/release/rust_birkana.exe" "-Wl,--gc-sections" "-nodefaultlibs" "-L" "/home/developer/target/x86_64-pc-windows-gnu/release/deps" "-L" "/home/developer/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib" "-Wl,-Bstatic" "-Wl,-Bdynamic" "/home/developer/target/x86_64-pc-windows-gnu/release/deps/libsvg-e43e83b8936467b2.rlib" "/home/developer/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/libstd-5c6cf767.rlib" "/home/developer/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/libpanic_unwind-5c6cf767.rlib" "/home/developer/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/libunwind-5c6cf767.rlib" "/home/developer/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/librand-5c6cf767.rlib" "/home/developer/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/libcollections-5c6cf767.rlib" "/home/developer/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/librustc_unicode-5c6cf767.rlib" "/home/developer/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/liblibc-5c6cf767.rlib" "/home/developer/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/liballoc-5c6cf767.rlib" "/home/developer/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/liballoc_system-5c6cf767.rlib" "/home/developer/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/libcore-5c6cf767.rlib" "-l" "ws2_32" "-l" "userenv" "-l" "shell32" "-l" "advapi32" "-l" "gcc_eh" "-l" "compiler-rt" "-lmingwex" "-lmingw32" "-lgcc" "-lmsvcrt" "-luser32" "-lkernel32" "/home/developer/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/rsend.o"
  = note: /usr/bin/ld: unrecognized option '--enable-long-section-names'
/usr/bin/ld: use the --help option for usage information
collect2: error: ld returned 1 exit status

what I find strange, is even when default toolchain is set to windows-gnu, in the command passed to gcc contains the path to linux-gnu toolchain. But not all commands, some are windows-gnu, but some not. I'm not sure if this is by design, or some bug.

But I tried everything I could think of and find on the internet, but it is impossible right now to cross-compile from mac or linux -> windows.

[bozaro]

As workaround you can create .cargo/config with content like (it works on my Linux host):

[target.i686-pc-windows-gnu]
linker = "i686-w64-mingw32-gcc"

[target.x86_64-pc-windows-gnu]
linker = "x86_64-w64-mingw32-gcc"

Directory .cargo can be located near Cargo.toml file.

[lunemec]

I added the second line and now it can't find the linker. Do I need to install it from somewhere?

error: could not exec the linker `x86_64-w64-mingw32-gcc`: No such file or directory (os error 2)

[retep998]

@lunemec If you're on Linux and trying to cross compile to Windows, yes you need to install the appropriate MinGW toolchain.

[bozaro]

I don't known. I have not a Mac OS :(

[lunemec]

I was running this command inside debian jessie inside docker on my macbook. I also installed the toolchain with rustup. It is shown in my previous post. Is this separate toolchain from rustup's toolchain (and components)? Where do I find it?

[bozaro]

May be:

sudo apt update && sudo apt install mingw-w64

[lunemec]

Yes! this indeed was the last step to getting it to compile. However, this is really terrible user experience with cross-compilation (yes I know it is difficult problem to solve right), but Golang is much much easier with their GOOS= ... setting (and 1 tar.gz download). I very much hope Rust will get there someday :)

Also, I'll open issue of this in rustup project, since none of this is documented.

[lilianmoraru]

Sorry for the spam(I repeated this in 1 issue and 1 merge request) but I searched for a more appropriate issue.

rust/src/libstd/sys/mod.rs

Line 37 in 1572bf1

#[cfg(unix)]

- this would block cross-compilation.
It will cross-compile to Unix targets only if the host is Unix(CYGWIN is included of course) and cross-compile to Windows targets only if the host is Windows.

I have not checked other files, it just so happened that I was working on a library that needs functions that are exported from that module and I observed that redox was using target_os which initially I thought is wrong but realized later that it is correct, the other 2 are wrong.

[eddyb]

cfg(unix) is a shorthand for cfg(target_family = "unix") (windows is similar).
I am not awake of cfg values provided by the compiler that describe the host.

[lilianmoraru]

Ok, than I misunderstood what cfg([os]) does.
I searched for docs and could not find anything, so this seemed more intuitive to me...

Edit: Google...
I went now to the Rust reference because I remembered reading something about it there, and I found it...

[liquidnight2]

I , too, have the issue with undefined reference to_Unwind_Resume and undefined reference to _Unwind_RaiseException

What is the way to go from here to compile from linux to windows ?

My setup consists of:

• Gentoo Linux x86_64 , sys-devel/crossdev-20160602-r1 , rustup 1.0.0,
• rustup targets : i686-pc-windows-gnu (installed) x86_64-pc-windows-gnu (installed)
• cargo 0.16.0-nightly (6e0c18c 2017-01-27)
• rustc 1.15.1 (021bd29 2017-02-08)
• src/main.rs : pub fn main() { println!("HelloWorld"); } , no dependencies
• ~/.cargo/config: [target.i686-pc-windows-gnu]
  linker = "i686-w64-mingw32-gcc"
• cargo build -v --target i686-pc-windows-gnu

How does

• "Those two symbols aren't defined in all mingw toolchains, but they're the ones that we want." play together with
• http://stackoverflow.com/questions/15670169 "The Dwarf-2 EH implementation for Windows is not designed at all to work under 64-bit Windows applications." ??

[DeadNumbers]

~/.cargo/config

[target.x86_64-pc-windows-gnu]
linker = "/usr/bin/x86_64-w64-mingw32-gcc"

[target.i686-pc-windows-gnu]
linker = "/usr/bin/i686-w64-mingw32-gcc"
rustflags = "-C panic=abort"

run

$ cargo rustc --target=i686-pc-windows-gnu --release -- -C link-args=-mwindows
   Compiling t v0.1.0 (file:///tmp/t)
    Finished release [optimized] target(s) in 3.72 secs

[liquidnight2]

Thanks. The rustflags trick worked for me. The resulting binary works with wine.

[zacps]

I'm trying to compile from x86_64 linux to x86_64 windows.

I can compile with:

cargo  rustc --bin $A --target=x86_64-pc-windows-gnu -- -C linker=x86_64-w64-mingw32-gcc

but compiling with:

cargo build --target=x86_64-pc-windows-gnu

fails (with OP's error) even with:

[target.x86_64-pc-windows-gnu]
linker = "x86_64-w64-mingw32-gcc'

What's the difference between the two commands and is there anything I'm doing wrong in the cargo build example?

[retep998]

@zacps Your .cargo/config example has a typo, because your string starts with " but ends with '. Also, are you sure you're putting that into a .cargo/config and that cargo is finding it?

[zacps]

@retep998 Ahh I had just gotten confused between the manifest and cargo's config file.
Thanks!

[aleksmelnikov]

@mati865 Yes, I wrote some comments about it there #55444 (comment)
And I have assembled i686 mingw toolchain with DWARF2 exceptions several days ago.

[rich-murphey]

This is a workaround I use on ubuntu 18.04 for the x86_64-pc-windows-gnu target.

sudo apt install -y gdb-mingw-w64 gcc-mingw-w64-x86-64
rustup target add x86_64-pc-windows-gnu
cat >~/.cargo/config <<EOF
[target.x86_64-pc-windows-gnu]
linker = "/usr/bin/x86_64-w64-mingw32-gcc"
ar = "/usr/x86_64-w64-mingw32/bin/ar"
EOF

[lokegustafsson]

I have similar problems. I run arch. The mingw-things are installed I think:

$ yay -Qs mingw
local/mingw-w64-binutils 2.33.1-1 (mingw-w64-toolchain mingw-w64)
    Cross binutils for the MinGW-w64 cross-compiler
local/mingw-w64-crt 7.0.0-1 (mingw-w64-toolchain mingw-w64)
    MinGW-w64 CRT for Windows
local/mingw-w64-gcc 9.2.0-1 (mingw-w64-toolchain mingw-w64)
    Cross GCC for the MinGW-w64 cross-compiler
local/mingw-w64-headers 7.0.0-1 (mingw-w64-toolchain mingw-w64)
    MinGW-w64 headers for Windows
local/mingw-w64-winpthreads 7.0.0-1 (mingw-w64-toolchain mingw-w64)
    MinGW-w64 winpthreads library

Rustup info:

$ rustup show
Default host: x86_64-unknown-linux-gnu
rustup home:  /home/loke/.rustup

installed targets for active toolchain
--------------------------------------

wasm32-unknown-unknown
x86_64-pc-windows-gnu
x86_64-unknown-linux-gnu

active toolchain
----------------

stable-x86_64-unknown-linux-gnu (default)
rustc 1.39.0 (4560ea788 2019-11-04)

$ cat ~/.cargo/config
[target.x86_64-pc-windows-gnu]
linker = "/usr/bin/x86_64-w64-mingw32-gcc"
ar = "/usr/x86_64-w64-mingw32/bin/ar"

Building gives these errors that I do not understand...

$ cargo build --release --target x86_64-pc-windows-gnu
   Compiling binary-accretion v0.1.0 (/home/loke/prog/binary-accretion)
error: linking with `/usr/bin/x86_64-w64-mingw32-gcc` failed: exit code: 1
  |
  = note: "/usr/bin/x86_64-w64-mingw32-gcc" "-Wl,--enable-long-section-names" "-fno-use-linker-plugin" "-Wl,--nxcompat" "-nostdlib" "-m64" "/home/loke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/crt2.o" "/home/loke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/rsbegin.o" "-L" "/home/loke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps/binary_accretion-7bfebb7089d410af.binary_accretion.1vvhdks2-cgu.0.rcgu.o" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps/binary_accretion-7bfebb7089d410af.binary_accretion.1vvhdks2-cgu.1.rcgu.o" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps/binary_accretion-7bfebb7089d410af.binary_accretion.1vvhdks2-cgu.10.rcgu.o" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps/binary_accretion-7bfebb7089d410af.binary_accretion.1vvhdks2-cgu.11.rcgu.o" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps/binary_accretion-7bfebb7089d410af.binary_accretion.1vvhdks2-cgu.12.rcgu.o" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps/binary_accretion-7bfebb7089d410af.binary_accretion.1vvhdks2-cgu.13.rcgu.o" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps/binary_accretion-7bfebb7089d410af.binary_accretion.1vvhdks2-cgu.14.rcgu.o" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps/binary_accretion-7bfebb7089d410af.binary_accretion.1vvhdks2-cgu.15.rcgu.o" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps/binary_accretion-7bfebb7089d410af.binary_accretion.1vvhdks2-cgu.2.rcgu.o" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps/binary_accretion-7bfebb7089d410af.binary_accretion.1vvhdks2-cgu.3.rcgu.o" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps/binary_accretion-7bfebb7089d410af.binary_accretion.1vvhdks2-cgu.4.rcgu.o" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps/binary_accretion-7bfebb7089d410af.binary_accretion.1vvhdks2-cgu.5.rcgu.o" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps/binary_accretion-7bfebb7089d410af.binary_accretion.1vvhdks2-cgu.6.rcgu.o" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps/binary_accretion-7bfebb7089d410af.binary_accretion.1vvhdks2-cgu.7.rcgu.o" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps/binary_accretion-7bfebb7089d410af.binary_accretion.1vvhdks2-cgu.8.rcgu.o" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps/binary_accretion-7bfebb7089d410af.binary_accretion.1vvhdks2-cgu.9.rcgu.o" "-o" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps/binary_accretion-7bfebb7089d410af.exe" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps/binary_accretion-7bfebb7089d410af.qrsntl0enzf1260.rcgu.o" "-Wl,--gc-sections" "-nodefaultlibs" "-L" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps" "-L" "/home/loke/prog/binary-accretion/target/release/deps" "-L" "/home/loke/.cargo/registry/src/github.com-1ecc6299db9ec823/winapi-x86_64-pc-windows-gnu-0.4.0/lib" "-L" "/home/loke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib" "-Wl,-Bstatic" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps/libminifb-34ec572c235437d4.rlib" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps/libraw_window_handle-80e54066af2928d7.rlib" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps/liblibc-f9604e2813c04637.rlib" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps/libtime-c57c1ae5347610c7.rlib" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps/libwinapi-c398f2f8b7d8dc98.rlib" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps/librayon-16d0215b3c8437b7.rlib" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps/librayon_core-feee4684abe71076.rlib" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps/libnum_cpus-18c0fa0adc89e949.rlib" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps/libcrossbeam_queue-ff041be37bcf2f46.rlib" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps/libcrossbeam_deque-17ef97ca7b7a18f9.rlib" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps/libcrossbeam_epoch-10ea9d0cfab31c58.rlib" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps/libscopeguard-6471871a291a00e0.rlib" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps/libmemoffset-6c2846be1364f0d5.rlib" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps/libcrossbeam_utils-7a31f82dafc9b1d9.rlib" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps/liblazy_static-1f4d2eef09ed0ef1.rlib" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps/libeither-386b2f2e547fc4df.rlib" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps/librand-f3ae1c3b5f096949.rlib" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps/librand_chacha-ddd5fec064267200.rlib" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps/libc2_chacha-2ef36a0c4d6b6e59.rlib" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps/libppv_lite86-826d4b03ad816244.rlib" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps/librand_core-98e9a5e9646a454e.rlib" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps/libgetrandom-838e18821aad5d0c.rlib" "/home/loke/prog/binary-accretion/target/x86_64-pc-windows-gnu/release/deps/libcfg_if-e8d51f745108570b.rlib" "-Wl,--start-group" "/home/loke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/libstd-17369c5457c0a4ad.rlib" "/home/loke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/libpanic_unwind-36c53ec92691b40d.rlib" "/home/loke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/libhashbrown-6cdf98991945c711.rlib" "/home/loke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/librustc_std_workspace_alloc-c82caba0fad9dc40.rlib" "/home/loke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/libbacktrace-808c3225043d4ef4.rlib" "/home/loke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/libbacktrace_sys-c0bf1a59e7ad7627.rlib" "/home/loke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/librustc_demangle-3c42c398e9291e05.rlib" "/home/loke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/libunwind-2db1844a6fd303a2.rlib" "/home/loke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/libcfg_if-499400abe2eee96a.rlib" "/home/loke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/liblibc-a0a9e961e3ae1d08.rlib" "/home/loke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/liballoc-5be10685e65dd2b6.rlib" "/home/loke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/librustc_std_workspace_core-cef13a7ba3b8fda4.rlib" "/home/loke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/libcore-f76cd49e5444665b.rlib" "-Wl,--end-group" "/home/loke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/libcompiler_builtins-477d6ada7584f678.rlib" "-Wl,-Bdynamic" "-lwinapi_advapi32" "-lwinapi_credui" "-lwinapi_gdi32" "-lwinapi_kernel32" "-lwinapi_msimg32" "-lwinapi_opengl32" "-lwinapi_secur32" "-lwinapi_user32" "-lwinapi_winspool" "-ladvapi32" "-ladvapi32" "-lws2_32" "-luserenv" "-Wl,-Bstatic" "-lgcc_eh" "-lpthread" "-Wl,-Bdynamic" "-lmingwex" "-lmingw32" "-lgcc" "-lmsvcrt" "-lmsvcrt" "-luser32" "-lkernel32" "/home/loke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/rsend.o"
  = note: /usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: /home/loke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/crt2.o:crtexe.c:(.text+0x7d): undefined reference to `_encode_pointer'
          /usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: /home/loke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/crt2.o:crtexe.c:(.rdata$.refptr.__onexitbegin[.refptr.__onexitbegin]+0x0): undefined reference to `__onexitbegin'
          /usr/lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld: /home/loke/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib/crt2.o:crtexe.c:(.rdata$.refptr.__onexitend[.refptr.__onexitend]+0x0): undefined reference to `__onexitend'
          collect2: error: ld returned 1 exit status
          

error: aborting due to previous error

error: could not compile `binary-accretion`.

To learn more, run the command again with --verbose.

What are _encode_pointer, __onexitbegin and __onexitend? If there is anything else I should add to this post please tell me.

[mati865]

@lokegustafsson your issue is related to #47048

You should be able to fix it by running this command every time you update Rust toolchain:

cp -f /usr/x86_64-w64-mingw32/lib/{,dll}crt2.o `rustc --print sysroot`/lib/rustlib/x86_64-pc-windows-gnu/lib

[badboy]

Rust 1.44.0 made this issue resurface for us.
Related bugs: #47493, #53301

Error

  = note: /usr/bin/i686-w64-mingw32-ld: /home/circleci/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/i686-pc-windows-gnu/lib/libstd-d4d98dbb25b105db.rlib(std-d4d98dbb25b105db.std.f5jmee2i-cgu.0.rcgu.o): in function `ZN64_$LT$std..backtrace..BytesOrWide$u20$as$u20$core..fmt..Debug$GT$3fmt17h26758117dc811c22E':
          /rustc/49cae55760da0a43428eba73abcb659bb70cf2e4\/src\libstd/backtrace.rs:229: undefined reference to `_Unwind_Resume'
          /usr/bin/i686-w64-mingw32-ld: /home/circleci/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/i686-pc-windows-gnu/lib/libstd-d4d98dbb25b105db.rlib(std-d4d98dbb25b105db.std.f5jmee2i-cgu.0.rcgu.o): in function `ZN4core3ops8function6FnOnce9call_once17h6cef60404fcca0f6E':
          /rustc/49cae55760da0a43428eba73abcb659bb70cf2e4\src\libcore\ops/function.rs:232: undefined reference to `_Unwind_Resume'
          /usr/bin/i686-w64-mingw32-ld: /home/circleci/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/i686-pc-windows-gnu/lib/libstd-d4d98dbb25b105db.rlib(std-d4d98dbb25b105db.std.f5jmee2i-cgu.0.rcgu.o): in function `ZN4core3ops8function6FnOnce9call_once17hffda90729e2269daE':
          /rustc/49cae55760da0a43428eba73abcb659bb70cf2e4\src\libcore\ops/function.rs:232: undefined reference to `_Unwind_Resume'
          /usr/bin/i686-w64-mingw32-ld: /home/circleci/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/i686-pc-windows-gnu/lib/libstd-d4d98dbb25b105db.rlib(std-d4d98dbb25b105db.std.f5jmee2i-cgu.0.rcgu.o): in function `ZN4core3ptr13drop_in_place17ha996cfbc1bafe8e3E':
          /rustc/49cae55760da0a43428eba73abcb659bb70cf2e4\src\libcore\ptr/mod.rs:177: undefined reference to `_Unwind_Resume'
          /usr/bin/i686-w64-mingw32-ld: /home/circleci/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/i686-pc-windows-gnu/lib/libstd-d4d98dbb25b105db.rlib(std-d4d98dbb25b105db.std.f5jmee2i-cgu.0.rcgu.o): in function `ZN4core3ptr13drop_in_place17h93bc3d652337e0b6E':
          /rustc/49cae55760da0a43428eba73abcb659bb70cf2e4\src\libcore\ptr/mod.rs:177: undefined reference to `_Unwind_Resume'
          /usr/bin/i686-w64-mingw32-ld: /home/circleci/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/i686-pc-windows-gnu/lib/libstd-d4d98dbb25b105db.rlib(std-d4d98dbb25b105db.std.f5jmee2i-cgu.0.rcgu.o):/rustc/49cae55760da0a43428eba73abcb659bb70cf2e4\src\libcore\ptr/mod.rs:177: more undefined references to `_Unwind_Resume' follow
          collect2: error: ld returned 1 exit status

Happens on this minimal code:

pub fn hello_world() -> i32 {
  31
}

and set to compile as a cdylib in Cargo.toml ([lib] crate-type = ['cdylib'])

Compiled like this:

RUSTFLAGS="-C panic=abort" cargo build --target i686-pc-windows-gnu

The above fails on Rust 1.44.0
The above compiles fine on Rust 1.43.0.
Enabling LTO also works for this minimal example:

RUSTFLAGS="-C panic=abort -C lto" cargo build --target i686-pc-windows-gnu

On our larger project compilation works in release mode (--release).
e enable opt-level = "s" and lto in the release profile, I haven't yet tried if any of these options affect it.

mingw gcc:

$ i686-w64-mingw32-gcc --version
i686-w64-mingw32-gcc (GCC) 9.2-win32 20191008
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[badboy]

(Ah well, I guess the original issue as reported wasn't due to the missing symbols, but at least the title matched, the other linked issues are suited better I guess)

[mati865]

@badboy it could be caused by refactoring of panic handling which happened in 1.44 but it's only a guess.
AFAIK i686 MinGW target is only supported with Dwarf-2 exception handling. Debian and its derivatives still provide only SJLJ exceptions for i686 MinGW though.

[badboy]

@badboy it could be caused by refactoring of panic handling which happened in 1.44 but it's only a guess.
AFAIK i686 MinGW target is only supported with Dwarf-2 exception handling. Debian and its derivatives still provide only SJLJ exceptions for i686 MinGW though.

Yup, saw the refactoring PR, that was also my first guess.
Not supporting that is fine I guess.
I guess we're running into this because libstd/libcore are compiled with panic=unwind, not our code. Still makes #53301 relevant again.

[mati865]

Using xargo, cargo-xbuild crates or unstable -Zbuild-std flag to rebuild std with panic=abort should help but it's purely a workaround.

Yeah, fixing #53301 would be really nice.

[dubiousjim]

Status report. I'm running in a docker on Ubuntu:18.04 with gcc-mingw-w64-i686 installed, and CARGO_TARGET_I686_PC_WINDOWS_GNU_LINKER=i686-w64-mingw32-gcc. Linking my test app fails with undefined references to _Unwind_RaiseException, _Unwind_Resume, __mingwthr_key_dtor.

Tried setting RUSTFLAGS="-Cpanic=abort. Since I'm running tests, that forces me to also use nightly and -Zpanic_abort_tests. But undefined references persist. Based on @mati865's comment, I tried also setting -Zbuild-std, but the nightly I'm getting doesn't recognize that option. Also tried -Clink-args=-mwindows, based on an older suggestion above, but it didn't help either.

So currently not able to compile from Ubuntu:18.04 (on x86_64) to the i686-pc-windows-gnu target. (Don't know if a small test app would work. My test app tries to link in LibreSSL libraries that it managed to build using the cross-compiler.)

[mati865]

I tried also setting -Zbuild-std, but the nightly I'm getting doesn't recognize that option.

It's cargo argument.

[dubiousjim]

I see, I was passing it via RUSTFLAGS to (nightly) rustc, but it needs to be passed to (nightly) cargo?

[mati865]

Yes, like that:
cargo +nightly -Z unstable-options -Zbuild-std

[infinity0]

I tried writing a patch to have rustc 32-bit windows use sjlj, but later found out someone already tried it (#55444), and there was an explanation on why it would take much more effort.

panic=abort sounds like too much of a nasty hack with unforeseeable other consequences (like the break from 1.43 -> 1.44), I've asked the Debian MinGW maintainer to consider adding or switching to dw2.

[mati865]

I am not suggesting that we provide 4 toolchains, only 3, the 3rd one being win32+dw2. We could call it gcc-mingw-w64-i686-win32+dw2 for example.

@infinity0 Rust uses pthreads so that toolchain would have to be posix+dw2.

[infinity0]

@mati865 where is that documented? I was going off #37409 via google which says

On 32-bit MinGW, however, we use the standard MinGW libraries for an unwinding implementation. On the pthreads toolchain these libraries reference pthread symbols, which we don't link by default. On the win32 toolchain these libraries link the win32 symbols, which we do indeed link by default.

[infinity0]

I also managed to build cargo fine with win32 threads, so assumed it was fine.

[mati865]

@infinity0 the explanation for building Rust with MinGW:

rust/src/ci/github-actions/ci.yml

Line 493 in 3323691

# We are using MinGW with POSIX threads since LLVM requires

Pthreads are linked here:

rust/src/librustc_llvm/build.rs

Line 306 in e8b55a4

// Libstdc++ depends on pthread which Rust doesn't link on MinGW

You are building only std for MinGW target so you very likely won't need pthreads here (this code won't be built).

---

Since GCC libs use pthread with POSIX toolchain we had explicitly link pthread here:

rust/src/librustc_target/spec/windows_gnu_base.rs

Line 56 in 3323691

"-l:libpthread.a".to_string(),

You can patch out it and then it should work with win32 threads.

[infinity0]

@mati865 So to summarise, pthreads is required if we need to link in libstdc++ is that right?

You can patch out it and then it should work with win32 threads.

Without patching anything, I built cargo.exe with win32 threads and it worked fine. So this part is confusing me.

However it sounds like, even if std/cargo builds fine with win32 threads, things will fail if the user wants to link in libstdc++ later, so I should follow suit and switch to the pthreads toolchain anyways.

[mati865]

@infinity0

So to summarise, pthreads is required if we need to link in libstdc++ is that right?

Yes, for std::thread (required by LLVM) with libstdc++ we need pthreads.

Without patching anything, I built cargo.exe with win32 threads and it worked fine. So this part is confusing me.

There are late_link_args_dynamic and late_link_args_static, one of them is always used depending if all crates are linked statically or not. If static version is used then -l:libpthread.a will be passed to the linker and it's only available in posix toolchain.

things will fail if the user wants to link in libstdc++ later

To make it clear, libstdc++ works with both win32 and posix threads. However with win32 threads it's missing many key features like std::thread that are required by LLVM and some other things so Rust didn't bother with that.

[mati865]

I think this issue should be closed since the original problem has been fixed.
Separate issues should be opened for each not fixed problem mentioned here.