[Rcpp-devel] Rcpp bug (was: [Rd] Notes on building a gcc toolchain for Rtools (but not multilib))

[Dirk Eddelbuettel]

Duncan,

The preferred and widely-documented address for Rcpp issues is rcpp-devel
where I am forwarding this, I would appreciate keeping follow-up there.

On 12 March 2015 at 15:11, Duncan Murdoch wrote:
| Jack (and Dirk):
| 
| I see this as well when I recompile Rcpp.
| 
| Dirk:  We're seeing the Rgui console on Windows lock up in 64 bit 
| Windows with a program calling Rf_error from Rcpp, but not from a simple 
| C program (attached) that looks equivalent.   This is using the new 
| toolchain, both to compile Rcpp and Jack's cppFunction() call below.
| 
| I'd be happy to help with debugging this, but not for a few days: I'll 
| be out of the office until Wednesday next week, and I don't have 64 bit 
| Windows when I'm on the road.

Sure.  We can pick this up when you are back.  The change vector appears to
be on your side of the fence so we need access from your end. Few of us (on
the Rcpp core group) use Windows all that much.

I think I saw a blog post mentioned where someone said that with g++ 4.9.2
(though possibly a different build/configuration/...) some exception-related
behaviour was improved.  I am sure that something is different now, and we
will try to accomodate it.

Safe travels.

Dirk

| 
| Duncan Murdoch
| 
| On 12/03/2015 2:54 PM, Duncan Murdoch wrote:
| > On 12/03/2015 1:31 PM, Jack Wasey wrote:
| > > Dear Duncan,
| > >
| > > I hope you don't mind me emailing you directly, rather than through
| > > r-devel, since it seemed a very specific problem. I had just sent an
| > > email to the list when it crossed with yours saying you had released a
| > > new Rtools, so I pulled my r-devel email. I have a probable R,
| > > possible Rcpp bug causing a hang with Rf_error("stop") after showing
| > > the error message, but only with 64 bit Rtools 3.3 (downloaded a few
| > > hours ago).
| > >
| > > I'm afraid my reproducible example uses Rcpp, but only for
| > > compilation. I'm not adept enough to eliminate the Rcpp step quickly,
| > > but I hope it will be of use anyway.
| > >
| > > Rcpp::cppFunction("void doError() { Rf_error(\"stopping\"); }")
| > > doError()
| > >
| > > This causes a hang after showing the error message. Winbuilder checked
| > > my package "icd9" without problems in 32 bit R-devel, and both 32 and
| > > 64 bit R current.
| > >
| > > Not being sure whether this is an Rcpp or R bug (see also
| > > https://github.com/RcppCore/Rcpp/issues/276), I hesitated to report
| > > this as a bug against R itself, but perhaps people more skilled than
| > > me can do this if indeed it is so.
| >
| > I see the same problem.  I've just tried the equivalent as a simple C
| > program, and it was fine.  I will try compiling Rcpp and see if that
| > fixes it; I wouldn't be surprised if the binary on CRAN was built with
| > the old compiler.
| >
| > Duncan Murdoch
| > >
| > > Best wishes,
| > > Jack
| > >
| > > On Thu, Mar 12, 2015 at 1:17 PM, Duncan Murdoch
| > > <murdoch.duncan at gmail.com> wrote:
| > > > I've just uploaded a minor update (3.3.0.1957) to Rtools33, adding the
| > > > cygpath.exe utility.  That utility converts between Windows style paths like
| > > > D:/Rtools and Cygwin style paths like /cygdrive/d/Rtools.   It may be useful
| > > > in configuration files if your external library expects to find gcc on the
| > > > path, since Rtools no longer puts it there.  Assuming you want to use the
| > > > Rtools toolchain, you can construct the path to the gcc directory in your
| > > > Makevars.win file as
| > > >
| > > > $(cygpath $(RTOOLS))gcc492_$(WIN)/bin
| > > >
| > > > (where RTOOLS and WIN are macros from RHOME/etc/*/Makeconf that should
| > > > already have been read.)
| > > >
| > > > Thanks to JJ Allaire for the prompting on this.
| > > >
| > > > Duncan Murdoch
| > > >
| > > > ______________________________________________
| > > > R-devel at r-project.org mailing list
| > > > https://stat.ethz.ch/mailman/listinfo/r-devel
| >
| 
| [DELETED ATTACHMENT test.c, plain text]

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