libgcc_eh.a hack no longer needed?

[jeroen]

I think the latest versions of rust on Windows no longer link to -lgcc_eh. I just released a version of gifski to CRAN that no longer has the libgcc_eh.a stub and all seems OK.

Can you confirm if you find the same?

[Ilia-Kosenkov]

Hi! Funny thing I am struggling with this right now. We unfortunately still rely on this, and new version of Rtools (42 & 43) does not have it, so we rely on hacks. What did you do to solve it?

[jeroen]

I upgraded rust to the latest version on windows, afaict, it no longer needs it. But perhaps something in my package stack changed as well, I'm not sure.

[Ilia-Kosenkov]

Can you be more specific on your setup? Which version of rtools do you use, which toolchain on windows and which target?

[Ilia-Kosenkov]

We currently do something like this

rextendr/inst/templates/Makevars.win

Line 22 in f8f964b

touch $(TARGET_DIR)/libgcc_mock/libgcc_eh.a

[Ilia-Kosenkov]

Also summoning @yutannihilation & @CGMossa since you both worked with this issue before.

[jeroen]

I removed the stub in r-rust/gifski@153c92f. You can see from the CI that it works with rtools43 and the latest rust. CRAN on Windows has Rust 1.69.0 now I think.

[Ilia-Kosenkov]

I am not sure I follow, but this looks to me like you are using Rtools40.

ADDPATH=$(subst C:,/c/,$(RTOOLS40_HOME))/mingw$(WIN)/bin:$(USERPROFILE)\.cargo\bin
export CARGO_TARGET_X86_64_PC_WINDOWS_GNU_LINKER=$(RTOOLS40_HOME)\mingw64\bin\gcc
export CARGO_TARGET_I686_PC_WINDOWS_GNU_LINKER=$(RTOOLS40_HOME)\\mingw32\bin\gcc

We use this linker

rextendr/inst/templates/Makevars.ucrt

Line 3 in f8f964b

CARGO_LINKER = x86_64-w64-mingw32.static.posix-gcc.exe

Don't get me wrong, I would be so happy if we could drop this hack, but right now I do not understand how.

[jeroen]

I am not sure I follow, but this looks to me like you are using Rtools40.

This part is only used on < R 4.2.

Don't get me wrong, I would be so happy if we could drop this hack, but right now I do not understand how.

I think you don't have to do anything, afaict, the latest rust simply no longer hardcodes -lgcc_eh as it did before.

[Ilia-Kosenkov]

Ok, I see. I will have to check this manually on our test projects. I hope it is so, this hack is painful to maintain. I will get back to you with results, thanks for letting us know!

[yutannihilation]

Thanks for sharing, Jeroen. Just for reference, it seems rustc itself still uses libgcc_eh (and libgcc_s).

https://github.com/rust-lang/rust/blob/1b67f8b013890fec98e4a2e72b568731d3a58c1f/compiler/rustc_target/src/spec/windows_gnu_base.rs#L64

[yutannihilation]

I confirmed it works without libgcc_eh.a at least on my local and on GHA.

yutannihilation/string2path#44

[yutannihilation]

It seems to work regardless of the version of Rust toolchain. So, if something was changed, it's probably on R's side? I don't setup the CI very carefully, so I might be wrong here.

https://github.com/yutannihilation/string2path/actions/runs/5036028906

[yutannihilation]

Oh, extendr fails. Curious.

https://github.com/extendr/extendr/actions/runs/5036073371/jobs/9031977734

[yutannihilation]

The failure happens on the test step, not on the build step. This is probably because cargo test requires unwinding (edit: Sorry, let me withdraw this part. Something must be different, but I don't know what it is.), whereas cargo build is not. So, I think this won't be a problem if the R package author tests only on R's side. If the author wants to write unit tests on Rust's side, they have to separate the crate (or use the fake libgcc_eh.a).