[R-SIG-Win] mingw-w64 toolchain status update

[Qiang Kou]

More update from my side:

(1) MinGW-w64:

I think we should take "mingw-builds", although it uses a different way to
build GCC.

The Rtools with GCC 4.6.3 used the cross-compiling method: it builds a
cross-compiler and then generates the Windows binaries. But I can't get
multilib support by using this method.

So "mingw-builds" seems a better solution, since it has multilib support.

(2) numerical precision

For reference, the bug is from
https://github.com/wch/r-source/blob/trunk/src/main/arithmetic.c#L217

Best wishes,

KK

On Fri, Aug 28, 2015 at 5:52 PM, Jeroen Ooms <jeroen.ooms at stat.ucla.edu>
wrote:

> Welcome to the new r-sig-windows mailing list! The initial purpose is
> to announce updates of the mingw-w64 tool chain (aka Rtools) and
> discuss problems related to building R and R packages on windows. Feel
> free to invite other people that might be interested in these
> developments.
>
> ## Building mingw-w64
>
> Several people have been working on and off on this over the past
> year. Below a summary of the current status to best of my knowledge.
> Please correct me where I am wrong.
>
> There are various collections of build-scripts available that produce
> a mingw-w64 tool-chain. Some cross compile from Linux, others are
> compile natively on Windows. In my experience, best results have been
> achieved using the "mingw-builds" [1] scripts, which build from the
> msys2 environment on windows. The "mingw-builds" scripts are pretty
> complete and well maintained. The mingw-w64 project itself uses these
> same scripts for publishing builds on their sourceforge website [2].
>
> Because we strive for maximum compatibility and minimal disruption, we
> target the same settings as the current rtools:
>
>  - i686 host (win32)
>  - sjlj exceptions
>  - win32 threads (not posix)
>  - static gcc (i.e. no separate libstdc++-6.dll and libgcc_s_sjlj-1.dll
> files)
>  - mingw-w64 runtime v3 (needed for c++11, current rtools has v2)
>
> When using sjlj exceptions, the mingw-builds defaults to a multilib
> toolchain. This means that the same compiler can target both win32 and
> win64 (using the -m32 and -m64 C flags). The current rtools uses a
> multilib tool chain as well, so R already passes the correct flags to
> the compiler, which makes the migration a little easier.
>
> I used the following command in msys2 to produce a gcc-4.9.2 build:
>
>   ./build --mode=gcc-4.9.2 --rt-version=v3 --arch=i686
> --exceptions=sjlj --static-gcc --threads=win32
> --enable-languages=c,c++,fortran
>
> Building took about 3 hours. A zip file with the binaries is available
> here [3]. The zip file is pretty large because the scripts also build
> a lot of extra utilities that we probably don't need in the final
> rtools distribution.
>
> ## Numeric precision bug
>
> One outstanding bug [4] in the mingw-w64 runtime can cause tiny
> numeric differences on 64bit windows. KK has found a simple workaround
> is to change R_pow (in src/main/arithmetic.c) to use powl() instead of
> pow().
>
>   sed -i "s/pow(x, y)/powl(x, y)/g" %R_HOME%/src/main/arithmetic.c
>
> I have confirmed that with this fix, R passes make check on win64.
> Hopefully base R can adopt this fix so that we don't need special
> patching for windows.
>
> ## Rf_error problem
>
> The mingw-w64 runtime version 3.3.0 had a bug [5] for sjlj exceptions
> that caused Rf_error() to crash. This problem has since then been
> fixed both the v3 and v4 versions of mingw-w64. Because the
> "mingw-builds" scripts always uses the latest v3.x version of
> mingw-w64, we do not need special patching anymore.
>
> In case we want to build a tool chain using the v3.3.0 version of the
> mingw runtime, KK has extracted the required patch:
> http://pastebin.com/k4dLndkw.
>
> ## Crashing V8
>
> There was a problem with the V8 package which would crash with the new
> tool chain. It looks like this was related to some ABI change in the
> mingw-w64 runtime. Rebuilding the libv8 library for i386 has solved
> the problem.
>
> ## Static Libraries
>
> I was able to build R-devel with the new tool chain using the same
> static libraries as for R 3.2.2 (libicu, libcairo, libcurl, Tcl, and
> the "extsoft" stuff in local320.zip, see [6]). However perhaps it
> couldn't hurt to rebuild some of these with more recent versions.
>
> ## To do
>
> There is still a lot of work to do. We need to do more more testing of
> R itself, in particular GUI features that are not covered by make
> check. Kevin already found a problem with tab completion in RGui that
> we need to investigate.
>
> Then we need to test if all CRAN packages work with the new tool
> chain. In particular packages that link to external C/C++ libraries,
> or those that use exotic c++ features might require attention.
>
> I will try to provide builds of the windows installer via [3] until
> the new tool chain is ready for CRAN. This installer contains both x32
> and x64 builds of R-devel, as well as a copy of the new tool chain
> itself.
>
> Thanks everyone for you help and patience!
>
>
> [1] https://github.com/niXman/mingw-builds/tree/develop
> [2]
> http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/
> [3] http://www.stat.ucla.edu/~jeroen/mingw-w64/
> [4] http://sourceforge.net/p/mingw-w64/bugs/466/
> [5] http://sourceforge.net/p/mingw-w64/bugs/465/
> [6] http://www.stats.ox.ac.uk/pub/Rtools
>
> _______________________________________________
> R-SIG-windows mailing list
> R-SIG-windows at r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-windows
>



-- 
Qiang Kou
qkou at umail.iu.edu
School of Informatics and Computing, Indiana University

	[[alternative HTML version deleted]]