From avraham.adler at gmail.com  Mon Jan 12 18:40:22 2015
From: avraham.adler at gmail.com (Avraham Adler)
Date: Mon, 12 Jan 2015 12:40:22 -0500
Subject: [Rd] New version of Rtools for Windows
Message-ID: <CAL6gwnLTKE=dKxwFYhiWxgpL+FT0RNkD4LqnsQMJwtPXTkdcaA@mail.gmail.com>

On Fri, Jan 9, 2015 at 12:19 PM, Duncan Murdoch
<murdoch.duncan at gmail.com> wrote:
> On 09/01/2015 10:56 AM, Henric Winell wrote:
>> On 2015-01-08 02:31, Duncan Murdoch wrote:
>>
>>> 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.
>>
>> Have you looked at nuwen's distro (http://nuwen.net/mingw.html)?  It's
>> up-to-date (mingw-w64 3.3.0, binutils 2.25, GCC 4.9.2, ...) and includes
>> the build scripts.
>>
>
> No, I hadn't come across that one.  It looks quite promising. Thanks!



If it helps, after installing the nuwen distro and the latest version
of Rtools (for tar), both the release R-3.1.2 and R-patched (see [1])
builds stop on Windows7 64bit with the error below, probably related
to what Hin-Tak Leung said earlier. I can't even get to the point to
see if compat.c will fail.


windres -F pe-x86-64   -i dllversion.rc -o dllversion.o
comm: file 1 is not in sorted order
Makefile.win:29: recipe for target 'Rgraphapp.def' failed
make[4]: *** [Rgraphapp.def] Error 1
makefile:120: recipe for target 'rlibs' failed
make[3]: *** [rlibs] Error 1
makefile:179: recipe for target '../../bin/x64/R.dll' failed
make[2]: *** [../../bin/x64/R.dll] Error 2
makefile:104: recipe for target 'rbuild' failed
make[1]: *** [rbuild] Error 2
makefile:14: recipe for target 'all' failed
make: *** [all] Error 2

[1] https://stackoverflow.com/questions/12802723/comm-file-1-is-not-in-sorted-order-when-compiling-r-source-in-windows



>
> I also have another offer of help to put this together; I'll wait to see
> how that goes before announcing it.  But having two builds is better
> than one.
>
> Duncan Murdoch
>
>
>>
>> Henric
>>
>>
>>
>>>
>>> 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/
>>>>
>>>
>>> ______________________________________________
>>> R-devel at r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



[Rd] New version of Rtools for Windows
Avraham Adler