Duplicating libgcc.a as libgcc_eh.a for both mingw64/mingw32 to solve -lgcc_eh linking problem

[Ilia-Kosenkov]

Fixes #185.
The "hack" that was introduced for mingw32 is expanded to work for any architecture.
gcc is build with --disable-shared, with which it does not produce a separate libgcc_eh.a, but rather puts everything into libgcc.a.
In some edge cases (like with Rust rustc compiler), a hard-coded -lgcc_eh results into linking error when rtools' mingw toolchain is used.

The duplication of libgcc.a as libgcc_eh.a solves this problem.

[yutannihilation]

(Just for information,) AppVeyor's error seems a timeout, not a test failure.

[jeroen]

I'm not opposed to merging this, but because gcc is part of the base rtools installation, we can't easily deploy this. I need to do a lot of testing before I can release a new rtools installer, this won't happen soon.

Also, just for be clear: there is nothing special about libgcc.a, another workaround would be to create some dummy libgcc_eh.a file in your project. The bug is that rust assumes it has to link to -lgcc_eh which is simply not needed. So you could literally put any file named libgcc_eh.a in your linker path to work around it.

[Ilia-Kosenkov]

@jeroen,
That is true that any file with that name put on the library search path can solve our problem.
However, we are suggesting this PR mainly because there is a 'hack' already implemented to solve this exact same problem, but it is implemented only for half of the cases. For us this means that we have to treat x86_64 differently, introducing extra conditions, as i686 currently works out of the box, because of the 'hack'. I can also imagine other cases and situations where hardcoded -lgcc_eh could ruin the compilation process, extendr is not the only project in such a situation.

So, even if it takes a lot of time to actually test and distribute to end-users, we are OK with that. We will use a temporary solution and later ask users to update rtools in our documentation.

[yutannihilation]

The bug is that rust assumes it has to link to -lgcc_eh which is simply not needed.

So, are you suggesting we should fix rustc, instead of rtoools?

[jeroen]

So, are you suggesting we should fix rustc, instead of rtoools?

Well it would be much better to fix this in rustc, instead of relying on a hack that may not exist in past or future versions of rtools, and in other static mingw-w64 toolchains.

My hack was really intended as a temporary fix, hoping that it would be fixed in rust. But I don't have the expertise myself to suggest a patch to rustc, which would omit the -lgcc_eh in static toolchains.

I am going to look for some advice to understand the problem better, what libgcc_eh provides and if we should include it in rtools.

[yutannihilation]

Thanks, sounds reasonable to me.

Looking at rust's repo quickly, it seems -lgcc_eh is inserted by these lines:

https://github.com/rust-lang/rust/blob/339e19697a39a78f4d669c217b7d21109215de41/compiler/rustc_target/src/spec/windows_gnu_base.rs#L52-L60

And, IIUC, this was added only less than a year ago, so the reason you needed that hack might not be the same one as this time.

rust-lang/rust@8e3467c#diff-1fb7094471bf1351ba3fabc9b5427e231582c58f302d0afe3b2fedbd7d51cb55R61

The discussion on the pull request is a bit lengthy so I couldn't follow all of them, but probably there should be some reason.

rust-lang/rust#67502