Skip to content

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

Closed

Description

@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

Activity

  1. added
    A-linkageArea: linking into static, shared libraries and binaries
    O-windows-gnuToolchain: GNU, Operating system: Windows
    on Sep 20, 2020
  2. added
    I-prioritizeIssue needs a team member to assess the impact. Will be replaced by P-{low,medium,high,critical}
    on Sep 20, 2020
  3. added
    E-needs-bisectionCall for participation: This issue needs bisection: https://github.com/rust-lang/cargo-bisect-rustc
    on Sep 20, 2020
  4. frxstrem commented on Sep 20, 2020

    @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.

  5. AndreKR commented on Sep 21, 2020

    @AndreKR
    Author

    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?

  6. mati865 commented on Sep 21, 2020

    @mati865
    Member

    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.

  7. added
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    on Sep 23, 2020
  8. hameerabbasi commented on Oct 1, 2020

    @hameerabbasi
    Contributor

    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.

  9. removed
    I-prioritizeIssue needs a team member to assess the impact. Will be replaced by P-{low,medium,high,critical}
    on Oct 1, 2020
  10. Xdminsy commented on Feb 5, 2021

    @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.

  11. mati865 commented on Feb 5, 2021

    @mati865
    Member

    @Xdminsy you can use link-self-contained=true codegen option to make Rust use only shipped linker.
    Example: RUSTFLAGS='-C link-self-contained=true'.

  12. Xdminsy commented on Feb 5, 2021

    @Xdminsy

    Ohh thank you, this environment variable seems to be a better way.

  13. tringcooler commented on Jan 27, 2024

    @tringcooler

    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.

    I changed the .cargo/config.toml like this:

    [target.x86_64-pc-windows-gnu]
    linker = "<your_gcc_path>\\bin\\ld.exe"
    rustflags = ["-L", "<your_rustup_path>\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\self-contained"]
    

    And it worked for me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-linkageArea: linking into static, shared libraries and binariesC-bugCategory: This is a bug.E-needs-bisectionCall for participation: This issue needs bisection: https://github.com/rust-lang/cargo-bisect-rustcO-windows-gnuToolchain: GNU, Operating system: WindowsT-compilerRelevant 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.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions