[Rcpp-devel] CRAN package does not build with Rcpp 0.11.1 and g++ 4.2.1
Dirk Eddelbuettel
edd at debian.org
Thu Feb 13 04:02:45 CET 2014
On 12 February 2014 at 18:44, Dan Tenenbaum 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?
Look at this repo, and its commits:
https://github.com/RcppCore/rcpp-logs
See eg the directory
https://github.com/RcppCore/rcpp-logs/tree/master/patches/2014-01
Who do you think I wrote these patches for?
I have no bone in the dogfight between Apple and the FSF, and it is not my
fault that those users are stuck at g++-4.2.* -- for now, or forever.
Romain works on a Mac, he possibly could test this but didn't care to.
I don't own a mac. Exactly what do you want me to do?
| 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.
Making Rcpp release is not trivial. As of today, we have 174 dependencies on
CRAN alone. You on BioC have about another 17. If *you* need an interim
release, make one locally has I have suggested before.
With this, I will try to no longer respond to your emails. They soak up a
fair amount of time and seem to achieve little. I'll cut my losses here.
Dirk
|
| 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
| >
--
Dirk Eddelbuettel | edd at debian.org | http://dirk.eddelbuettel.com
More information about the Rcpp-devel
mailing list