R devel - Mar 2015 - Windows gcc toolchain for R 3.2.0

To anyone following the Windows toolchain saga:

The gcc 4.9.2 toolchain that is currently in Rtools33 has too many 
incompatibilities with existing code, so we won't be using it in the R 
3.2.0 build.  I will soon be uploading to CRAN a new version of Rtools33 
that is very similar to Rtools32, containing gcc 4.6.3.

We are continuing to work on the new toolchain, and hope to have it 
ready before R 3.2.1 is released.

The known problems are as follows:

   - C++ code should not call Rf_error(), as it uses longjmp, and the 
behaviour of longjmp is undefined in C++ when destructors need to be 
called.  However, a number of packages do call Rf_error, and in gcc 
4.6.3, they get away with it.  In our candidate 4.9.2 build, they 
crashed.  If we can't work around this, I'll suggest that we test for 
the presence of Rf_error in C++ code, and start issuing warnings or 
errors when it is seen.  But before we do that, we need a solid replacement.

  - There are some other crashes that appear to be unrelated, also with 
C++ code.

  - There are some subtle differences in arithmetic that result in tests 
failing.  These may be due to bugs in MinGW-w64 code,
or may be unavoidable.

Duncan Murdoch

Duncan (and everybody else working on it behind the curtains),

Thanks for the update. All the work is truly appreciated, and it is really
too bad that we turned to C++ testing so late in the process.  But ensuring
release quality is paramount, so withholding g++ 4.9.* on Windows til these
issues are sorted out is the correct approach. 

On 18 March 2015 at 09:27, Duncan Murdoch wrote:
| called.  However, a number of packages do call Rf_error, and in gcc 
| 4.6.3, they get away with it.  In our candidate 4.9.2 build, they 

For the record, "we also got away with it" using every other know
compiler
and configuration. We would have addressed this earlier if it had been known.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org

Duncan,

----- Original Message -----
> From: "Duncan Murdoch" <murdoch.duncan at gmail.com>
> To: "R-devel at r-project.org" <r-devel at r-project.org>,
rcpp-devel at r-forge.wu-wien.ac.at
> Sent: Wednesday, March 18, 2015 6:27:26 AM
> Subject: [Rcpp-devel] Windows gcc toolchain for R 3.2.0
> 
> To anyone following the Windows toolchain saga:
> 
> The gcc 4.9.2 toolchain that is currently in Rtools33 has too many
> incompatibilities with existing code, so we won't be using it in the
> R
> 3.2.0 build.  I will soon be uploading to CRAN a new version of
> Rtools33
> that is very similar to Rtools32, containing gcc 4.6.3.
> 
> We are continuing to work on the new toolchain, and hope to have it
> ready before R 3.2.1 is released.
Thanks very much for your work on this.
> 
> The known problems are as follows:
> 
>    - C++ code should not call Rf_error(), as it uses longjmp, and the
> behaviour of longjmp is undefined in C++ when destructors need to be
> called.  However, a number of packages do call Rf_error, and in gcc
> 4.6.3, they get away with it.  In our candidate 4.9.2 build, they
> crashed.  If we can't work around this, I'll suggest that we test
for
> the presence of Rf_error in C++ code, and start issuing warnings or
> errors when it is seen.  But before we do that, we need a solid
> replacement.
> 
>   - There are some other crashes that appear to be unrelated, also
>   with
> C++ code.
> 
>   - There are some subtle differences in arithmetic that result in
>   tests
> failing.  These may be due to bugs in MinGW-w64 code,
> or may be unavoidable.
Is it not considered a "known problem" that C++ libraries linked
against by R packages need to be rebuilt with g++ 4.9.2 in order for the R
packages to install/load?

Thanks again,
Dan

> 
> Duncan Murdoch
> _______________________________________________
> Rcpp-devel mailing list
> Rcpp-devel at lists.r-forge.r-project.org
> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
>

On Wed, 2015-03-18 at 07:55 -0700, Dan Tenenbaum wrote:
> Is it not considered a "known problem" that C++ libraries linked
> against by R packages need to be rebuilt with g++ 4.9.2 in order for
> the R packages to install/load?
This could well be due to incompatible thread models (win32 vs posix).
See the thread "V8 crashes..." on the Rcpp-devel mailing list. We have
not yet had a chance to test the gcc 4.9.2 toolchain built with win32
threads.

Martyn
> Thanks again,
> Dan
-----------------------------------------------------------------------
This message and its attachments are strictly confidenti...{{dropped:8}}

I have updated and moved the notes on the new toolchain.  Their URL is

https://rawgit.com/kevinushey/RToolsToolchainUpdate/master/mingwnotes.html

Thanks to Kevin for setting this up.  Anyone who can solve the problems
on that page, or who finds a new problem, please get in contact with us
by email or on Github.

Duncan Murdoch

On 18/03/2015 9:27 AM, Duncan Murdoch wrote:
> To anyone following the Windows toolchain saga:
> 
> The gcc 4.9.2 toolchain that is currently in Rtools33 has too many 
> incompatibilities with existing code, so we won't be using it in the R 
> 3.2.0 build.  I will soon be uploading to CRAN a new version of Rtools33 
> that is very similar to Rtools32, containing gcc 4.6.3.
> 
> We are continuing to work on the new toolchain, and hope to have it 
> ready before R 3.2.1 is released.
> 
> The known problems are as follows:
> 
>    - C++ code should not call Rf_error(), as it uses longjmp, and the 
> behaviour of longjmp is undefined in C++ when destructors need to be 
> called.  However, a number of packages do call Rf_error, and in gcc 
> 4.6.3, they get away with it.  In our candidate 4.9.2 build, they 
> crashed.  If we can't work around this, I'll suggest that we test
for
> the presence of Rf_error in C++ code, and start issuing warnings or 
> errors when it is seen.  But before we do that, we need a solid
replacement.
> 
>   - There are some other crashes that appear to be unrelated, also with 
> C++ code.
> 
>   - There are some subtle differences in arithmetic that result in tests 
> failing.  These may be due to bugs in MinGW-w64 code,
> or may be unavoidable.
> 
> Duncan Murdoch
>