Hi, I have R version 2.8.1 and Rtools 28 installed (as you might guess, set up years ago). In Rtools the MinGW GCC 4.2 compiler toolset is included. For my regular C/C++ programs I have also installed, separately, the full MinGW bundle with the latest GCC 4.5 compiler tools. So I have two g++ variants on the same machine. According to the Rtools documentation, the bin directory of it shall be in the system PATH, and very early in the PATH (first elements). Presently the bin directory of the Rtools-MinGW is front. Fine but Ok for my daily C++ work I actually prefer that the regular (non-Rtools) MinGW compiler is invoked, hence I would prefer putting that in front. But then, of course, invoking g++ from R development would refer to the regular MinGW compiler toolset. When I do R development, would you expect it to cause problems if actually the regular MinGW (gcc 4.5) is invoked, and not the version that came bundled with Rtools (4.2) ? Or is this something I should better stay away from ? If not likely to work, what would you suggest to do instead ? thanks and best, Thomas
Rtools and MinGW
5 messages · Brian Ripley, Thomas Mang, Duncan Murdoch +1 more
On Sun, 3 Apr 2011, Thomas Mang wrote:
Hi, I have R version 2.8.1 and Rtools 28 installed (as you might guess, set up years ago). In Rtools the MinGW GCC 4.2 compiler toolset is included. For my regular C/C++ programs I have also installed, separately, the full MinGW bundle with the latest GCC 4.5 compiler tools. So I have two g++ variants on the same machine. According to the Rtools documentation, the bin directory of it shall be in the system PATH, and very early in the PATH (first elements). Presently the bin directory of the Rtools-MinGW is front. Fine but Ok for my daily C++ work I actually prefer that the regular (non-Rtools) MinGW compiler is invoked, hence I would prefer putting that in front. But then, of course, invoking g++ from R development would refer to the regular MinGW compiler toolset. When I do R development, would you expect it to cause problems if actually the regular MinGW (gcc 4.5) is invoked, and not the version that came bundled with Rtools (4.2) ? Or is this something I should better stay away from ? If not likely to work, what would you suggest to do instead ?
Follow the posting guide and update your R before posting .... We do not support ancient versions of R, and it is very likely that R 2.8.1 does not work correctly with gcc 4.5.2: there are incompatibilities in the argument passing.
thanks and best, Thomas
Brian D. Ripley, ripley at stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595
On 04.04.2011 11:04, Prof Brian Ripley wrote:
On Sun, 3 Apr 2011, Thomas Mang wrote:
Hi, I have R version 2.8.1 and Rtools 28 installed (as you might guess, set up years ago). In Rtools the MinGW GCC 4.2 compiler toolset is included. For my regular C/C++ programs I have also installed, separately, the full MinGW bundle with the latest GCC 4.5 compiler tools. So I have two g++ variants on the same machine. According to the Rtools documentation, the bin directory of it shall be in the system PATH, and very early in the PATH (first elements). Presently the bin directory of the Rtools-MinGW is front. Fine but Ok for my daily C++ work I actually prefer that the regular (non-Rtools) MinGW compiler is invoked, hence I would prefer putting that in front. But then, of course, invoking g++ from R development would refer to the regular MinGW compiler toolset. When I do R development, would you expect it to cause problems if actually the regular MinGW (gcc 4.5) is invoked, and not the version that came bundled with Rtools (4.2) ? Or is this something I should better stay away from ? If not likely to work, what would you suggest to do instead ?
Follow the posting guide and update your R before posting .... We do not support ancient versions of R, and it is very likely that R 2.8.1 does not work correctly with gcc 4.5.2: there are incompatibilities in the argument passing.
OK I can update but in general I think it's unlikely that the MinGW version bundled with Rtools will ever be the same as the regular MinGW version (even if just by update cycle delays). Is there any other way to tell Rtools where to search for MinGW-bin except of setting the globally applicable PATH variable ? Some configuration file or so ? thanks, Thomas
On 04/04/2011 6:34 AM, Thomas Mang wrote:
On 04.04.2011 11:04, Prof Brian Ripley wrote:
On Sun, 3 Apr 2011, Thomas Mang wrote:
Hi, I have R version 2.8.1 and Rtools 28 installed (as you might guess, set up years ago). In Rtools the MinGW GCC 4.2 compiler toolset is included. For my regular C/C++ programs I have also installed, separately, the full MinGW bundle with the latest GCC 4.5 compiler tools. So I have two g++ variants on the same machine. According to the Rtools documentation, the bin directory of it shall be in the system PATH, and very early in the PATH (first elements). Presently the bin directory of the Rtools-MinGW is front. Fine but Ok for my daily C++ work I actually prefer that the regular (non-Rtools) MinGW compiler is invoked, hence I would prefer putting that in front. But then, of course, invoking g++ from R development would refer to the regular MinGW compiler toolset. When I do R development, would you expect it to cause problems if actually the regular MinGW (gcc 4.5) is invoked, and not the version that came bundled with Rtools (4.2) ? Or is this something I should better stay away from ? If not likely to work, what would you suggest to do instead ?
Follow the posting guide and update your R before posting .... We do not support ancient versions of R, and it is very likely that R 2.8.1 does not work correctly with gcc 4.5.2: there are incompatibilities in the argument passing.
OK I can update but in general I think it's unlikely that the MinGW version bundled with Rtools will ever be the same as the regular MinGW version (even if just by update cycle delays). Is there any other way to tell Rtools where to search for MinGW-bin except of setting the globally applicable PATH variable ? Some configuration file or so ?
Why not just keep two PATH variables, and put one in place before R builds, the other in place the rest of the time? Duncan Murdoch
On Sun, Apr 3, 2011 at 3:36 PM, Thomas Mang
<thomasmang.ng at googlemail.com> wrote:
Hi, I have R version 2.8.1 and Rtools 28 installed (as you might guess, set up years ago). In Rtools the MinGW GCC 4.2 compiler toolset is included. For my regular C/C++ programs I have also installed, separately, the full MinGW bundle with the latest GCC 4.5 compiler tools. So I have two g++ variants on the same machine. According to the Rtools documentation, the bin directory of it shall be in the system PATH, and very early in the PATH (first elements). Presently the bin directory of the Rtools-MinGW is front. Fine but Ok for my daily C++ work I actually prefer that the regular (non-Rtools) MinGW compiler is invoked, hence I would prefer putting that in front. But then, of course, invoking g++ from R development would refer to the regular MinGW compiler toolset. When I do R development, would you expect it to cause problems if actually the regular MinGW (gcc 4.5) is invoked, and not the version that came bundled with Rtools (4.2) ? Or is this something I should better stay away from ? If not likely to work, what would you suggest to do instead ? thanks and best, Thomas
If you use Rcmd.bat from http://batchfiles.googlecode.com to build your packages then it will find Rtools using the registry rather than the path so if your other processing uses the path you can be using two different versions of Rtools transparently. (Alternately, in the same collection there is rtools.bat which will add the rtools bin directory to your path for the remainder of the current console session only so other console sessions can be using other versions of Rtools.) Also both of these will look for an R_TOOLS environment variable and use that instead of the registry if present so you could set that for even further customization (although from your description you won't likely need to do that). You might need to use a back version of Rcmd.bat since your version of R is pretty old but all back versions are still available.
Statistics & Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com