Issues detecting RTools toolchain, 4.2 onwards

[weshinsley]

Describe the bug
rtools4x_toolchain_path has the incorrect path for the RTools 4.2, 4.3 or 4.4 toolchain,
so never finds it, and always calls pacman, installing another version of the toolchain
into the existing RTools folder. Doing this creates some problems which I'll describe
in additional context

To Reproduce
On a windows machine with a fresh RTools 4.4 installed and the environment variable
RTOOLS44_HOME correctly set, call check_rtools4x_windows_toolchain().

Expected behavior
It should find the Rtools toolchain. We were surprised to find another toolchain
installed into the existing Rtools structure.

Operating system
Windows 10

CmdStanR version number
0.8.0

Additional context

See #978

The problem is a little more complex than it seems for us, although the PR I made
fixes things for our current workflow.

There is an issue in the current public install of RTools 4.4
caused in binutils, in which if the RTools library is on a network share with a drive
letter, at the link stage, the network share gets translated into a UNC path, and then
the linker fails to handle that UNC path correctly.

This was worked-around for us talking to the RTools team, and currently that patch
is on our RTools, which is used by cluster users.

The version that gets installed by cmdstanr currently does not have that patch, so all
stan jobs fail because of the binutils problem. So we cannot run stan at present
while the issue with binutils remains, and while Stan pulls in that particular version.

If cmdstanr uses the existing RTools toolchain, that problem goes away for us, and
we can run stan models again from our cluster.

We were a bit surprised that cmdstanr caused actual changes to the contents of our
RTools installation, meaning we have multiple g++.exe versions (one v13, one v14)
which we did not have before, and had not installed ourselves.

I have made a very simple PR which restores cmdstanr functionality for us for now.

[weshinsley]

I see from the already-closed PR that this functionality is intentional - it looked like an oversight to me since the line of code I changed would have been the correct path for Rtools 4.0, but not for 4.2 onwards.

Never-the-less, we have show-stopping issues as far as cmdstanr goes with the different toolchain that gets pulled in, because of the binutils bug.

[andrjohns]

I'll add an option to allow forcing the use of the RTools toolchain without installing additional utilities, but you'll need to be using the CmdStan 2.35 RC - otherwise you won't be able to build the TBB and you might have issues with complex numbers

[weshinsley]

Ok - thanks - we'll switch to 2.35 RC and await...

I believe the issue in binutils has been addressed so with future releases that part of the issue will hopefully resolve too.

[kalibera]

I'll add an option to allow forcing the use of the RTools toolchain without installing additional utilities, but you'll need to be using the CmdStan 2.35 RC - otherwise you won't be able to build the TBB and you might have issues with complex numbers

Please try to avoid installing any Msys2 toolchains to Rtools installations of users as soon as possible. Mixing the toolchains is likely to cause trouble not only in this case, but also in other, due to incompatibilities in the runtime, C++ library, etc - this is also one of the reasons why it is not allowed on CRAN to download pre-compiled static libraries. It is normal that even GCC has bugs and they will get fixed: both in Rtools and in Msys2, once fixed upstream in GCC, sometimes even sooner than that. That a fix comes faster in one toolchain than the other should not be a reason to mix them, and definitely not to make a package mix the toolchains in user's Rtools.

The issue with complex numbers Andrew found has been reported to GCC and I will work that around in Rtools if not fixed fast enough upstream:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115122
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115117

Msys2 isn't affected because they are building gcc natively (not cross-compiling).

The issue with UNC paths Wes found has been worked around in a development version of Rtools (in gcc) and will be part of the next release. It seems it has been fixed upstream in binutils in their development version. Msys2 doesn't have that work-around, so exhibits the binutils bug, as Wes found out via cmdstanr installing an Msys2 toolchain.

Re TBB: I am not aware or may have forgotten - is there an unresolved issue in Rtools preventing a build of TBB?

[andrjohns]

Yes, I've updated our makefiles and documentation to work with stock RTools from the next CmdStan release, and this will be the default once we submit to CRAN.

The TBB issue was just assumptions in their makefiles about the shell and path handling (which RcppParallel had patched in their bundled copy long ago)

[andrjohns]

@weshinsley You can now set the CMDSTANR_USE_RTOOLS environment variable to specify the use of the stock toolchain