"cannot find -lgcc_eh" since nightly-2020-09-08-x86_64-pc-windows-gnu

[AndreKR]

Empty cargo project with fn main() {}. Target is nightly-2020-09-08-x86_64-pc-windows-gnu, there's the latest (9.2.0) GCC from TDM-GCC in the PATH.

$ cargo build
   Compiling rusttest v0.1.0 (C:\dev-projects\rusttest)
error: linking with `x86_64-w64-mingw32-gcc` failed: exit code: 1
  |
[...]
  = note: C:/dev-tools/TDM-GCC-64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lgcc_eh
          collect2.exe: error: ld returned 1 exit status

I tried pinpointing the exact version where it breaks, but because some nightlies are broken I could only determine a range:

rustup default ...	Result
nightly-2020-08-29	Builds ok
nightly-2020-08-30	no release found
nightly-2020-08-31	no release found
nightly-2020-09-01	no release found
nightly-2020-09-02	error: component 'rustfmt' [...] is unavailable [...]
nightly-2020-09-03	error: component 'rustfmt' [...] is unavailable [...]
nightly-2020-09-04	error: component 'rustfmt' [...] is unavailable [...]
nightly-2020-09-05	error: component 'rustfmt' [...] is unavailable [...]
nightly-2020-09-06	error: component 'rustfmt' [...] is unavailable [...]
nightly-2020-09-07	Build error

[frxstrem]

I'm able to reproduce with TDC-GCC (9.2.0) but not with MinGW-w64 GCC (10.2.0), so it seems to be compiler specific. If I'm not mistaken, only MinGW is officially supported.

I was not able to get cargo-bisect-rustc working for this (it seemed to fail for every nightly going months back, for some reason), but through manual bisection I found that rustc 1.48.0-nightly (80fc9b0ec 2020-09-02) succeeds compilation, whereas rustc 1.48.0-nightly (0d0f6b113 2020-09-03) fails. So I believe that the change was somewhere in the range 80fc9b0...0d0f6b1.

[AndreKR]

I removed the TDM-GCC directory from my PATH and I did not add any other directory to it and now Rust/Cargo is using .multirust\toolchains\nightly-x86_64-pc-windows-gnu\lib\rustlib\x86_64-pc-windows-gnu\bin\self-contained\ld.exe and everything works. 👍 It's a bit unexpected for me that it will prefer tools in the PATH over the bundled ones, can I disable that behavior?

[mati865]

It was changed in #76167

@AndreKR you can disable it with -C link-self-contained=yes.
To avoid using it everytime you can add it to cargo config:

[target.i686-pc-windows-gnu]
rustflags=["-Clink-self-contained=yes"]
[target.x86_64-pc-windows-gnu]
rustflags=["-Clink-self-contained=yes"]

It's a bit unexpected for me that it will prefer tools in the PATH over the bundled ones

The motivation for this change was the fact when crate builds C code it will use compiler from the path (Rust bundles linker but not the compiler).
Combining libraries linked with different MinGW versions is very unlikely to succeed so it was decided to prefer using system linker when available.

[hameerabbasi]

According to the WG-prioritization discussion on Zulip, we have decided to close this issue, as TDM-GCC is unsupported, and there's a workaround available.

[Xdminsy]

Say I meet this problem today when I just want to compile a hello world rust file.
rustc main.rs gives error: linking failed. cannot find -lgcc_eh, the same as this issue.

As I don't want to remove tdm-gcc from my $PATH, then I try to find another workaround.
I know that it cannot find -lgcc_eh is because of the lack of its library file, namely libgcc_eh.a.
But the file libgcc_eh.a is not shipped with tdm-gcc.
I don't know why but it may be a fault or tradeoff of tdm-gcc itself, I figure it's gcc's exception handling library.

So I just copied the libgcc_eh.a from .rustup\toolchains\stable-x86_64-pc-windows-gnu\lib\rustlib\x86_64-pc-windows-gnu\lib\self-contained to C:\Program Files\TDM-GCC-64\lib\gcc\x86_64-w64-mingw32\9.2.0, and it compiles and runs.
No more cannot find -lgcc_eh. (I guess copying this file from mingw-w64 may also work).

Well, I only tried the hello world file and a hello world cargo project.
But this means seems to be a useful workaround.