I have just uploaded to CRAN a new version 3.2.0.1948 of Rtools for Windows. This will become visible there in a few hours, and be copied to mirrors thereafter. People who want to build packages that include compiled code can use this to supply the compilers, etc., that are necessary for the build. It also includes some extra materials for people who want to build R itself. This version includes only minor updates to the tools. I indicated last summer that I was hoping to update GCC from the current version 4.6.3 before the R 3.2.0 release, but this now looks unlikely, unless someone else with experience building it can help. (I need a new build script for it that I can run, not just a binary copy. So far I have been unsuccessful in updating the scripts inhttp://www.stats.ox.ac.uk/pub/Rtools/multilib/multi.zip , or finding other scripts online that work.) Duncan Murdoch
On Wed, Jan 7, 2015 at 8:00 AM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote:> > This version includes only minor updates to the tools. I indicated last summer that I was hoping to update GCC from the current version 4.6.3 before the R 3.2.0 release, but this now looks unlikely, unless someone else with experience building it can help.I have been looking into this a bit over the past few months, also with mixed success. Nevertheless, below some experiences that might be worth sharing. The guys from mingw-w64 recommended (quite strongly) to move away from multilib. They explained that the standard approach is to create two separate toolchains; one that targets win32 and the other one that targets win64 (both tool chains can compiled for win32). Hence the only difference for R would be that instead of passing "-m64" and "-m32", it would need to set the path to the proper compiler. There are several initiatives that provide very complete suites of precompiled mingw-w64 tools. I think the ideal scenario would be if we could take advantage of an existing tool chain as we do on other platforms, although perhaps I do not fully understand the R-specific requirements on the windows compiler. One project that looks very promising is msys2 [1,2]. It has a package manager (port of pacman from arch linux) and comes with a pretty complete set of msys [3] and other [4] packages that seems quite well maintained. The only issue I ran into with msys2 is that it uses a different c++ exception model (seh/dwarf) than the current Rtools (which uses sjlj). See also [5]. Therefore, if a library uses exceptions, we cannot use the current Rtools to link a static library that was created with msys2 [6]. I am not sure if it also be a problem the other way around, and if this is still the case for recent versions of gcc/mingw. Finally, Ruby has build very similar to Rtools called DevKit-mingw64 [7] that we might be able to borrow from. [1] https://msys2.github.io/ [2] http://stackoverflow.com/questions/25019057/how-are-msys-msys2-and-msysgit-related-to-each-other [3] https://github.com/Alexpux/MSYS2-packages [4] https://github.com/Alexpux/MINGW-packages [5] http://stackoverflow.com/questions/15670169/what-is-difference-between-sjlj-vs-dwarf-vs-seh [6] http://stackoverflow.com/questions/7751640/undefined-reference-to-gxx-personality-sj0 [7] http://rubyinstaller.org/downloads/
On 07/01/2015 5:20 PM, Jeroen Ooms wrote:> On Wed, Jan 7, 2015 at 8:00 AM, Duncan Murdoch <murdoch.duncan at gmail.com> wrote: >> >> This version includes only minor updates to the tools. I indicated last summer that I was hoping to update GCC from the current version 4.6.3 before the R 3.2.0 release, but this now looks unlikely, unless someone else with experience building it can help. > > I have been looking into this a bit over the past few months, also > with mixed success. Nevertheless, below some experiences that might be > worth sharing. > > The guys from mingw-w64 recommended (quite strongly) to move away from > multilib. They explained that the standard approach is to create two > separate toolchains; one that targets win32 and the other one that > targets win64 (both tool chains can compiled for win32). Hence the > only difference for R would be that instead of passing "-m64" and > "-m32", it would need to set the path to the proper compiler. > > There are several initiatives that provide very complete suites of > precompiled mingw-w64 tools. I think the ideal scenario would be if we > could take advantage of an existing tool chain as we do on other > platforms, although perhaps I do not fully understand the R-specific > requirements on the windows compiler.I feel quite strongly that we need to be able to build the toolchain, rather than relying on binaries produced by others. We may need to customize the toolchain, or we may need to rebuild it when a bug is identified. Lots of binary builders abandon their builds and you can't count on them to solve problems at a later date.> > One project that looks very promising is msys2 [1,2]. It has a package > manager (port of pacman from arch linux) and comes with a pretty > complete set of msys [3] and other [4] packages that seems quite well > maintained.Do they post complete instructions for building? That's what I'm looking for. I don't want to develop a build script (I don't know how), but I would like to have one. Duncan Murdoch> > The only issue I ran into with msys2 is that it uses a different c++ > exception model (seh/dwarf) than the current Rtools (which uses sjlj). > See also [5]. Therefore, if a library uses exceptions, we cannot use > the current Rtools to link a static library that was created with > msys2 [6]. I am not sure if it also be a problem the other way > around, and if this is still the case for recent versions of > gcc/mingw. > > Finally, Ruby has build very similar to Rtools called DevKit-mingw64 > [7] that we might be able to borrow from. > > > [1] https://msys2.github.io/ > [2] http://stackoverflow.com/questions/25019057/how-are-msys-msys2-and-msysgit-related-to-each-other > [3] https://github.com/Alexpux/MSYS2-packages > [4] https://github.com/Alexpux/MINGW-packages > [5] http://stackoverflow.com/questions/15670169/what-is-difference-between-sjlj-vs-dwarf-vs-seh > [6] http://stackoverflow.com/questions/7751640/undefined-reference-to-gxx-personality-sj0 > [7] http://rubyinstaller.org/downloads/ >