This is a reminder to update CI workflow
|
if ($env:RUST_TARGETS -like "*x86_64*") { |
|
<# Amend rtools libgcc_eh.a #> |
|
cp C:\rtools40\mingw64\lib\gcc\x86_64-w64-mingw32\8.3.0\libgcc.a C:\rtools40\mingw64\lib\gcc\x86_64-w64-mingw32\8.3.0\libgcc_eh.a |
in light of the recent merging of this PR
r-windows/rtools-packages#186.
The problem on Windows side is that MSYS2 (used for generating bindings), Rtools (custom MSYS2 build) and mingw toolchains in rust's *pc-windows-gnu ship different versions of gcc and friends. This creates issues that can be resolved using hacks (see code snippet above).
In particular, in PR r-windows/rtools-packages#186 we suggested implementing a hack that was present in 32-bit version of Rtools, but not in 64-bit version.
As soon as updated rtools gets released (I believe it will take significant time), we can update CI here. I hope with Rtools patched we may be able to move additional workflows to Rtools only, avoiding both MSYS2 and rust's own mingw tools.
This is a reminder to update CI workflow
libR-sys/.github/workflows/test.yml
Lines 264 to 266 in ccdf5d5
in light of the recent merging of this PR r-windows/rtools-packages#186.
The problem on Windows side is that MSYS2 (used for generating bindings), Rtools (custom MSYS2 build) and mingw toolchains in rust's
*pc-windows-gnuship different versions of gcc and friends. This creates issues that can be resolved using hacks (see code snippet above).In particular, in PR r-windows/rtools-packages#186 we suggested implementing a hack that was present in 32-bit version of Rtools, but not in 64-bit version.
As soon as updated rtools gets released (I believe it will take significant time), we can update CI here. I hope with Rtools patched we may be able to move additional workflows to Rtools only, avoiding both MSYS2 and rust's own
mingwtools.