Repository navigation
"cannot find -lgcc_eh" since nightly-2020-09-08-x86_64-pc-windows-gnu #76984
Copy link
Copy link
Closed
Labels
A-linkageArea: linking into static, shared libraries and binariesArea: linking into static, shared libraries and binariesC-bugCategory: This is a bug.Category: This is a bug.E-needs-bisectionCall for participation: This issue needs bisection: https://github.com/rust-lang/cargo-bisect-rustcCall for participation: This issue needs bisection: https://github.com/rust-lang/cargo-bisect-rustcO-windows-gnuToolchain: GNU, Operating system: WindowsToolchain: GNU, Operating system: WindowsT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.regression-from-stable-to-nightlyPerformance or correctness regression from stable to nightly.Performance or correctness regression from stable to nightly.
Description
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 |
Metadata
Metadata
Assignees
Labels
A-linkageArea: linking into static, shared libraries and binariesArea: linking into static, shared libraries and binariesC-bugCategory: This is a bug.Category: This is a bug.E-needs-bisectionCall for participation: This issue needs bisection: https://github.com/rust-lang/cargo-bisect-rustcCall for participation: This issue needs bisection: https://github.com/rust-lang/cargo-bisect-rustcO-windows-gnuToolchain: GNU, Operating system: WindowsToolchain: GNU, Operating system: WindowsT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.regression-from-stable-to-nightlyPerformance or correctness regression from stable to nightly.Performance or correctness regression from stable to nightly.
Activity
frxstrem commentedon Sep 20, 2020
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-rustcworking for this (it seemed to fail for every nightly going months back, for some reason), but through manual bisection I found thatrustc 1.48.0-nightly (80fc9b0ec 2020-09-02)succeeds compilation, whereasrustc 1.48.0-nightly (0d0f6b113 2020-09-03)fails. So I believe that the change was somewhere in the range 80fc9b0...0d0f6b1.AndreKR commentedon Sep 21, 2020
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.exeand 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 commentedon Sep 21, 2020
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:
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 commentedon Oct 1, 2020
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 commentedon Feb 5, 2021
Say I meet this problem today when I just want to compile a hello world rust file.
rustc main.rsgiveserror: 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_ehis because of the lack of its library file, namelylibgcc_eh.a.But the file
libgcc_eh.ais 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.afrom.rustup\toolchains\stable-x86_64-pc-windows-gnu\lib\rustlib\x86_64-pc-windows-gnu\lib\self-containedtoC:\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.
mati865 commentedon Feb 5, 2021
@Xdminsy you can use
link-self-contained=truecodegen option to make Rust use only shipped linker.Example:
RUSTFLAGS='-C link-self-contained=true'.Xdminsy commentedon Feb 5, 2021
Ohh thank you, this environment variable seems to be a better way.
tringcooler commentedon Jan 27, 2024
I changed the .cargo/config.toml like this:
And it worked for me.