[Rcpp-devel] CRAN package does not build with Rcpp 0.11.1 and g++ 4.2.1

Thu Feb 13 03:53:01 CET 2014

Yes, the patch is trivial. Dan, we can try installing the latest version of
Rcpp on GitHub on the BioC Mac build machine and confirm that these
packages do build on Mac with llvm-g++4.2. And I agree that either 1. CRAN
needs to rebuild the binaries for packages linking to Rcpp, or 2. these
package maintainers need to send a maintenance bump. Of course, they can do
neither until we submit a fixed version of Rcpp to CRAN, because
essentially the bug means, IIUC, that any package using Rcpp Modules cannot
be built with llvm-g++4.2.

My opinion is that we should submit a maintenance release after issues on
everyone's favourite OS, Solaris, are confirmed to be worked out.

Cheers,
Kevin

On Wed, Feb 12, 2014 at 6:44 PM, Dan Tenenbaum <dtenenba at fhcrc.org> wrote:

> Hi Dirk,
>
> Sorry for the typo in my subject.
>
> Very briefly:
>
> There are three CRAN packages (probably more) that can't be run from
> binaries and they can't be recompiled (with CRAN's default compiler for the
> platform).
>
> Therefore anyone who wants to use these 3 packages on a Mac is SOL. They
> could compile them if they downloaded Xcode and clang. That's asking a lot
> more than we typically ask of CRAN users on a Mac. I'm talking about
> ordinary end users, not developers.
>
> All three packages can be fixed with a patch like the one Kevin made for
> mzR. But that patch belongs in Rcpp. If the patch is not applied to Rcpp,
> it does no good to other packages which we still haven't discovered won't
> build with g++ 4.2.1.
>
> If you knew that all packages with dependencies on Rcpp would need to be
> rebuilt, why did you not ask the maintainers of all these packages to bump
> their version numbers? That would solve the problem in many cases (or at
> least expose cases where there were g++ 4.2.1 compilation problems).
> Instead CRAN is pushing out unusable binaries to the world. Seems to me
> it's a lot simpler to do the rebuilding once -- on CRAN -- than to ask Mac
> and Windows non-developer users to do it, over and over, using software not
> installed by default on those platforms. This means that all the automated
> building that CRAN does every day is for naught, as far as these
> packages/platforms are concerned.
>
> I am trying to help, here. This is not about solving problems at
> Bioconductor--I'm trying to point out problems lurking on CRAN. It's
> wonderful that Kevin is in my building but that's not germane here.
>
> I think the patch required for Rcpp is trivial--Kevin can correct me if
> I'm wrong.
>
> Dan
>
>
>
>
>
> ----- Original Message -----
> > From: "Dirk Eddelbuettel" <edd at debian.org>
> > To: "Dan Tenenbaum" <dtenenba at fhcrc.org>
> > Cc: "rcpp-devel" <rcpp-devel at lists.r-forge.r-project.org>
> > Sent: Wednesday, February 12, 2014 6:09:38 PM
> > Subject: Re: [Rcpp-devel] CRAN package does not build with Rcpp 0.11.1
> and g++        4.2.1
> >
> >
> > Dan,
> >
> > [ Impossible Subject:, there is no Rcpp 0.11.1 amywhere yet. ]
> >
> > On 12 February 2014 at 17:19, Dan Tenenbaum wrote:
> > | The CRAN package ConConPiWiFun does not compile under g++ 4.2.1
> > | which is the default compiler on the CRAN build machine (see
> > | http://cran.us.r-project.org/web/checks/check_flavors.html, the
> > | row r-release-macosx-x86_64).
> > |
> > | This has not been a problem so far because the package has not been
> > | rebuilt since November 5. But the next time the package is
> > | updated, it will fail to build on the CRAN mac build machine,
> > | unless the issue that causes the failure is addressed.
> > |
> > | The error is:
> > |
> > | [...]
> > |
> /Library/Frameworks/R.framework/Versions/3.1/Resources/library/Rcpp/include/Rcpp/Reference.h:34:
> > | note:
> > |
> Rcpp::Reference_Impl<StoragePolicy>::Reference_Impl(const
> > | Rcpp::Reference_Impl<StoragePolicy>&) [with StoragePolicy =
> > | Rcpp::PreserveStorage]
> > | make: *** [Modules.o] Error 1
> > | ERROR: compilation failed for package 'ConConPiWiFun'
> > | * removing
> > |
> '/Library/Frameworks/R.framework/Versions/3.1/Resources/library/ConConPiWiFun'
> > | * restoring previous
> > |
> '/Library/Frameworks/R.framework/Versions/3.1/Resources/library/ConConPiWiFun'
> > |
> > | This is the same error that has been discussed before on this list
> > | in the context of the Bioconductor package mzR.
> > |
> > | Apparently the problem is caused by the fact that g++ 4.2.1 does
> > | not create a default constructor; clang++ and newer versions of
> > | g++ can deal with this.
> > |
> > | This same problem occurs with other CRAN packages, among them:
> > |
> > | lm.br
> > | RSofia
> >
> > They all passed when I did my checks -- Ubuntu 13.10, g++-4.8.  I do
> > not
> > claim to have the resources to test all package against all
> > compilers.
> >
> > If you want to retest all CRAN package, I'll happily walk you through
> > my
> > scripts. Preferably off-list.
> >
> > | I didn't test exhaustively; there could be more.
> > |
> > | More concerning, installing the binary versions of these packages
> > | and then loading them causes errors that may be related to Rcpp:
> >
> > I was under the impression that you knew you needed to _recompile_.
> >
> > | > library(ConConPiWiFun)
> > | Loading required package: Rcpp
> > | Error in .doLoadActions(where, attach) :
> > |   error in load action .__A__.1 for package ConConPiWiFun:
> > |   loadModule(module = "mod_cplfunction", what = TRUE, env = ns, :
> > |   Unable to load module "mod_cplfunction": unimplemented type
> > |   'any' in 'eval'
> > |
> > | Error: package or namespace load failed for 'ConConPiWiFun'
> > |
> > |
> > | > library(lm.br)
> > | Loading required package: Rcpp
> > |
> > |  *** caught segfault ***
> > | address 0x1d00000031, cause 'memory not mapped'
> > | Error in .doLoadActions(where, attach) :
> > |   error in load action .__A__.1 for package lm.br:
> > |   loadModule(module = "Clmbr", what = TRUE, env = ns, loadNow =
> > |   TRUE): Unable to load module "Clmbr": 'getCharCE' must be called
> > |   on a CHARSXP
> > | Error: package or namespace load failed for 'lm.br'
> > |
> > | > library(RSofia)
> > | Loading required package: Rcpp
> > |
> > |  *** caught segfault ***
> > | address 0x0, cause 'unknown'
> > |
> > | [...]
> > |
> > |
> > | This suggests that these packages need to be rebuilt against Rcpp
> > | 0.11.0,
> >
> > Yes, we knew. That is from the release announcement dated Feb 3 where
> > I say
> >
> >    [...]  This does however mean that your current packages using
> >    Rcpp will
> >    break, so you need rebuild all packages using Rcpp this one time.
> >     [...]
> >
> > | and either patched to deal with the compiler/constructor issue, or
> > | perhaps
> > | that issue can be addressed in Rcpp itself.
> >
> > Kevin has taken care of the mzR / constructor issue.  May I once
> > again
> > suggest that you take advantage of the fact he works in your building
> > /
> > institution and try to sort this out locally?
> >
> > Thanks so much.
> >
> > Dirk
> >
> > |
> > | Thanks,
> > | Dan
> > |
> > | > sessionInfo()
> > | R version 3.0.2 Patched (2013-12-18 r64488)
> > | Platform: x86_64-apple-darwin10.8.0 (64-bit)
> > |
> > | locale:
> > | [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
> > |
> > | attached base packages:
> > | [1] stats     graphics  grDevices utils     datasets  methods
> > |   base
> > | _______________________________________________
> > | 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
> > --
> > Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com
> >
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20140212/2e0100f0/attachment-0001.html>