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
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 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
Maybe Matching Threads
- Setting the path to Rtools for package compilation on Windows
- newly install old and present R versions
- RV: Reporting a conflict between ADMB and Rtools on Windows systems
- Can't build termstrc package from source
- Rtools contains Python interpreter(s), and six copies?