What is (or can be) the plan to support Rtools42 on r-lib/actions?

Just curious. I recently got to know the current Rtools40 is on a collision course against Rtools42.

c.f. https://github.com/r-windows/r-base/pull/34#issuecomment-1001213439

It seems r-lib/actions still uses Rtools40. I know it works fine as it contains /ucrt64 toolchain, but, still, I think the CI setup should match with the officially recommended one. Are there any plan to migrate to Rtools42? Or, do we need to migrate to Tomas Kalibera's GitHub Action eventually?

We will add support for Rtools42 and probably make it the default for R 4.2.x at some point.

1 Like

Thanks for clarifying! But, IIUC, CRAN already uses Rtools42 for building R-devel and doing CRAN checks, so I'm afraid checking with Rtools40 might not be very reliable. Why is the plan still "at some point"? Is it that there are some problem on R-core's (or CRAN's?) side?

There isn't a good reason to hurry, as far as I can tell.

I just checked, the official CRAN R-devel installer is still built with Rtools40, and Rtools42 is not available for download from the CRAN mirrors. Once there is a stable download URL for Rtools42 on CRAN, I'll add optional support for it at r-lib/actions.

Once R 4.2.0 is out, GitHub will hopefully include Rtools42 on their Windows images.

If you want to check your package with ucrt now, Rtools40 works fine for that, at least I haven't seen any cases where it didn't. If we find some cases then I'll add Rtools42 earlier.

Why do you think that? Rtools40 and Rtools42 actually use the same compiler version for ucrt builds.

Which is not the case for any suggested r-lib/actions configuration, btw: all Linux and macOS configurations use different compilers than CRAN.

the official CRAN R-devel installer is still built with Rtools40

Oh, really...? Then, it's just I'm confusing with the official blog post by the R-core members. It says:

On Monday December 13, CRAN will switch the incoming checks on Windows to what is now “ucrt3”. At the same time, R-devel source code will be patched with “ucrt3” patches. From that point on, it will assume 64-bit UCRT and no longer support MSVCRT nor 32-bit targets, and CRAN will start building R-devel snapshot binary builds with Rtools42.

Sorry that I didn't confirm it enough, and sorry for taking your time for this...

Why do you think that? Rtools40 and Rtools42 actually use the same compiler version for ucrt builds.

There are several differences I'm concerning about:

  1. path: Rtools42 uses C:/rtools42/x86_64-w64-mingw32.static.posix/bin.
  2. envvar: Rtools42 uses RTOOLS42_HOME instead of RTOOLS40_HOME.
  3. absence of 32-bit toolchains.

You are right in that these don't matter for usual packages as the compiler versions are the same, but I'm developing a package that compiles Rust code, which needs to handle these differences in the toolchain.

So, in short, I agree there isn't a good reason to hurry. Thinking this again, it seems it's just I'm relatively hurry for my own reason.

(And, on a side note, I'm really hoping the R-core will reconsider their decision that makes everyone get lost...)

Yes, maybe that was the plan, but the R-devel installer is still built with Rtools40, by Jeroen. You can see the digital signature in Windows Explorer -> Properties. It is true that it does not support MSVCRT and 32 bit targets any more, though. As I understand CRAN's plan is now to switch over to their own daily builds during the current CRAN winter break.

You should not rely on that. People can install Rtools40 and Rtools42 wherever they want to. I am not even sure where they are installed on GHA.

If you really need to rely on that, then you can do it conditionally. You can use pkgbuild to detect the Rtools path, or you can copy the code from it. It looks like this: pkgbuild/R/rtools.R at 161f7d31d23da1c89fe9959679a6fd3150eba515 · r-lib/pkgbuild · GitHub

That is the same for both, Rtools40 also does not have 32 bit ucrt compilers.

Again, if you need to know the location of the compilers, I suggest you use the pkgbuild package, or write similar code to detect the location.

Yeah, we rely on pkgbuild for finding the path to Rtools, thanks for that :slight_smile:

One more difference I forgot to mention is that the paths (x86_64-w64-mingw32.static.posix/bin) are hard coded in R's source code. I don't think this will cause any major problem, but I'm just a bit uneasy about these subtle differences. Anyway, I'll wait until they get ready...

That does not matter much, because R 4.2.0 will rely on the PATH for finding the compiler.

Yes, R does find it, but Rust might not.

And I found it actually matters to me (I guess this is my problem and few people will hit this, so please just ignore. This is just for information). I get this error,

x error: linker `x86_64-w64-mingw32-gcc` not found

because of this difference ¯\_(ツ)_/¯

$ find /c/rtools40 -name '*gcc.exe'
/c/rtools40/mingw32/bin/gcc.exe
/c/rtools40/mingw32/bin/i686-w64-mingw32-gcc.exe
/c/rtools40/mingw64/bin/gcc.exe
/c/rtools40/mingw64/bin/x86_64-w64-mingw32-gcc.exe
/c/rtools40/ucrt64/bin/gcc.exe
/c/rtools40/ucrt64/bin/x86_64-w64-mingw32-gcc.exe

$ find /c/rtools42 -name '*gcc.exe'
/c/rtools42/x86_64-w64-mingw32.static.posix/bin/gcc.exe
/c/rtools42/x86_64-w64-mingw32.static.posix/bin/x86_64-w64-mingw32.static.posix-gcc.exe

This is a bug in pkgbuild then, no? It should tell you to use the /c/rtools42/x86_64-w64-mingw32.static.posix/bin path.

Can you please open a pkgbuild issue with an example that reproduces your issue? Thanks!

Thanks, once I figure out if this is a bug on pkgbuild's side, I'll do. Still investigating...

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.

If you have a query related to it or one of the replies, start a new topic and refer back with a link.