<div dir="ltr">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.<div>
<br></div><div>My opinion is that we should submit a maintenance release after issues on everyone's favourite OS, Solaris, are confirmed to be worked out.</div><div><br></div><div>Cheers,</div><div>Kevin</div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Wed, Feb 12, 2014 at 6:44 PM, Dan Tenenbaum <span dir="ltr"><<a href="mailto:dtenenba@fhcrc.org" target="_blank">dtenenba@fhcrc.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Dirk,<br>
<br>
Sorry for the typo in my subject.<br>
<br>
Very briefly:<br>
<br>
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).<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
I think the patch required for Rcpp is trivial--Kevin can correct me if I'm wrong.<br>
<span class="HOEnZb"><font color="#888888"><br>
Dan<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
<br>
----- Original Message -----<br>
> From: "Dirk Eddelbuettel" <<a href="mailto:edd@debian.org">edd@debian.org</a>><br>
> To: "Dan Tenenbaum" <<a href="mailto:dtenenba@fhcrc.org">dtenenba@fhcrc.org</a>><br>
> Cc: "rcpp-devel" <<a href="mailto:rcpp-devel@lists.r-forge.r-project.org">rcpp-devel@lists.r-forge.r-project.org</a>><br>
> Sent: Wednesday, February 12, 2014 6:09:38 PM<br>
> Subject: Re: [Rcpp-devel] CRAN package does not build with Rcpp 0.11.1 and g++ 4.2.1<br>
><br>
><br>
> Dan,<br>
><br>
> [ Impossible Subject:, there is no Rcpp 0.11.1 amywhere yet. ]<br>
><br>
> On 12 February 2014 at 17:19, Dan Tenenbaum wrote:<br>
> | The CRAN package ConConPiWiFun does not compile under g++ 4.2.1<br>
> | which is the default compiler on the CRAN build machine (see<br>
> | <a href="http://cran.us.r-project.org/web/checks/check_flavors.html" target="_blank">http://cran.us.r-project.org/web/checks/check_flavors.html</a>, the<br>
> | row r-release-macosx-x86_64).<br>
> |<br>
> | This has not been a problem so far because the package has not been<br>
> | rebuilt since November 5. But the next time the package is<br>
> | updated, it will fail to build on the CRAN mac build machine,<br>
> | unless the issue that causes the failure is addressed.<br>
> |<br>
> | The error is:<br>
> |<br>
> | [...]<br>
> | /Library/Frameworks/R.framework/Versions/3.1/Resources/library/Rcpp/include/Rcpp/Reference.h:34:<br>
> | note:<br>
> | Rcpp::Reference_Impl<StoragePolicy>::Reference_Impl(const<br>
> | Rcpp::Reference_Impl<StoragePolicy>&) [with StoragePolicy =<br>
> | Rcpp::PreserveStorage]<br>
> | make: *** [Modules.o] Error 1<br>
> | ERROR: compilation failed for package ‘ConConPiWiFun’<br>
> | * removing<br>
> | ‘/Library/Frameworks/R.framework/Versions/3.1/Resources/library/ConConPiWiFun’<br>
> | * restoring previous<br>
> | ‘/Library/Frameworks/R.framework/Versions/3.1/Resources/library/ConConPiWiFun’<br>
> |<br>
> | This is the same error that has been discussed before on this list<br>
> | in the context of the Bioconductor package mzR.<br>
> |<br>
> | Apparently the problem is caused by the fact that g++ 4.2.1 does<br>
> | not create a default constructor; clang++ and newer versions of<br>
> | g++ can deal with this.<br>
> |<br>
> | This same problem occurs with other CRAN packages, among them:<br>
> |<br>
> | <a href="http://lm.br" target="_blank">lm.br</a><br>
> | RSofia<br>
><br>
> They all passed when I did my checks -- Ubuntu 13.10, g++-4.8. I do<br>
> not<br>
> claim to have the resources to test all package against all<br>
> compilers.<br>
><br>
> If you want to retest all CRAN package, I'll happily walk you through<br>
> my<br>
> scripts. Preferably off-list.<br>
><br>
> | I didn't test exhaustively; there could be more.<br>
> |<br>
> | More concerning, installing the binary versions of these packages<br>
> | and then loading them causes errors that may be related to Rcpp:<br>
><br>
> I was under the impression that you knew you needed to _recompile_.<br>
><br>
> | > library(ConConPiWiFun)<br>
> | Loading required package: Rcpp<br>
> | Error in .doLoadActions(where, attach) :<br>
> | error in load action .__A__.1 for package ConConPiWiFun:<br>
> | loadModule(module = "mod_cplfunction", what = TRUE, env = ns, :<br>
> | Unable to load module "mod_cplfunction": unimplemented type<br>
> | 'any' in 'eval'<br>
> |<br>
> | Error: package or namespace load failed for ‘ConConPiWiFun’<br>
> |<br>
> |<br>
> | > library(<a href="http://lm.br" target="_blank">lm.br</a>)<br>
> | Loading required package: Rcpp<br>
> |<br>
> | *** caught segfault ***<br>
> | address 0x1d00000031, cause 'memory not mapped'<br>
> | Error in .doLoadActions(where, attach) :<br>
> | error in load action .__A__.1 for package <a href="http://lm.br" target="_blank">lm.br</a>:<br>
> | loadModule(module = "Clmbr", what = TRUE, env = ns, loadNow =<br>
> | TRUE): Unable to load module "Clmbr": 'getCharCE' must be called<br>
> | on a CHARSXP<br>
> | Error: package or namespace load failed for ‘<a href="http://lm.br" target="_blank">lm.br</a>’<br>
> |<br>
> | > library(RSofia)<br>
> | Loading required package: Rcpp<br>
> |<br>
> | *** caught segfault ***<br>
> | address 0x0, cause 'unknown'<br>
> |<br>
> | [...]<br>
> |<br>
> |<br>
> | This suggests that these packages need to be rebuilt against Rcpp<br>
> | 0.11.0,<br>
><br>
> Yes, we knew. That is from the release announcement dated Feb 3 where<br>
> I say<br>
><br>
> [...] This does however mean that your current packages using<br>
> Rcpp will<br>
> break, so you need rebuild all packages using Rcpp this one time.<br>
> [...]<br>
><br>
> | and either patched to deal with the compiler/constructor issue, or<br>
> | perhaps<br>
> | that issue can be addressed in Rcpp itself.<br>
><br>
> Kevin has taken care of the mzR / constructor issue. May I once<br>
> again<br>
> suggest that you take advantage of the fact he works in your building<br>
> /<br>
> institution and try to sort this out locally?<br>
><br>
> Thanks so much.<br>
><br>
> Dirk<br>
><br>
> |<br>
> | Thanks,<br>
> | Dan<br>
> |<br>
> | > sessionInfo()<br>
> | R version 3.0.2 Patched (2013-12-18 r64488)<br>
> | Platform: x86_64-apple-darwin10.8.0 (64-bit)<br>
> |<br>
> | locale:<br>
> | [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8<br>
> |<br>
> | attached base packages:<br>
> | [1] stats graphics grDevices utils datasets methods<br>
> | base<br>
> | _______________________________________________<br>
> | Rcpp-devel mailing list<br>
> | <a href="mailto:Rcpp-devel@lists.r-forge.r-project.org">Rcpp-devel@lists.r-forge.r-project.org</a><br>
> | <a href="https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel" target="_blank">https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel</a><br>
> --<br>
> Dirk Eddelbuettel | <a href="mailto:edd@debian.org">edd@debian.org</a> | <a href="http://dirk.eddelbuettel.com" target="_blank">http://dirk.eddelbuettel.com</a><br>
><br>
_______________________________________________<br>
Rcpp-devel mailing list<br>
<a href="mailto:Rcpp-devel@lists.r-forge.r-project.org">Rcpp-devel@lists.r-forge.r-project.org</a><br>
<a href="https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel" target="_blank">https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel</a></div></div></blockquote></div><br></div>