Install Rcpp 0.12.12 from Source R 3.5.1

[adamrobinson361]

I am trying to install Rcpp 0.12.12 from source using the devtools::install_version on R 3.5.1 on Windows as follows:

devtools::install_version('Rcpp', '0.12.12')

This is resulting in the following error:

Downloading package from url: https://cran.rstudio.com//src/contrib/Archive/Rcpp/Rcpp_0.12.12.tar.gz
Installing Rcpp
"C:/PROGRA~1/R/R-35~1.1/bin/x64/R" --no-site-file --no-environ --no-save  \
  --no-restore --quiet CMD INSTALL  \
  "C:/Users/adamrobinson361/AppData/Local/Temp/RtmpMdPYR8/devtools424ceb379d/Rcpp"  \
  --library="C:/Program Files/R/R-3.5.1/library" --install-tests 

* installing *source* package 'Rcpp' ...
** package 'Rcpp' successfully unpacked and MD5 sums checked
Warning in as.POSIXlt.POSIXct(x, tz) :
  unable to identify current timezone 'C':
please set environment variable 'TZ'
** libs

*** arch - i386
c:/Rtools/mingw32/bin/g++  -I"C:/PROGRA~1/R/R-35~1.1/include" -DNDEBUG -I../inst/include/         -O2 -Wall  -mtune=generic -c Date.cpp -o Date.o
In file included from ../inst/include/RcppCommon.h:67,
                 from ../inst/include/Rcpp.h:27,
                 from Date.cpp:31:
../inst/include/Rcpp/sprintf.h: In function 'std::__cxx11::string Rcpp::sprintf(const char*, ...)':
../inst/include/Rcpp/sprintf.h:30:12: warning: unnecessary parentheses in declaration of 'ap' [-Wparentheses]
     va_list(ap);
            ^
In file included from ../inst/include/Rcpp.h:77,
                 from Date.cpp:31:
../inst/include/Rcpp/Rmath.h: In function 'double R::pythag(double, double)':
../inst/include/Rcpp/Rmath.h:222:57: error: '::Rf_pythag' has not been declared
     inline double pythag(double a, double b) { return ::Rf_pythag(a, b); }
                                                         ^~~~~~~~~
../inst/include/Rcpp/Rmath.h:222:57: note: suggested alternative: 'pythag'
     inline double pythag(double a, double b) { return ::Rf_pythag(a, b); }
                                                         ^~~~~~~~~
                                                         pythag
make: *** [C:/PROGRA~1/R/R-35~1.1/etc/i386/Makeconf:215: Date.o] Error 1
ERROR: compilation failed for package 'Rcpp'
* removing 'C:/Program Files/R/R-3.5.1/library/Rcpp'
In R CMD INSTALL

I understand from #826 that Rf_pythag has since been commented out and having tested with the latest version from cran with install.packages('Rcpp', type = 'source') I no longer have this problem.

Is this a known problem and should I be able to install from source for the specified version?

Session info as follows:

R version 3.5.1 (2018-07-02)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows >= 8 x64 (build 9200)

Matrix products: default

locale:
[1] LC_COLLATE=English_United States.1252  LC_CTYPE=English_United States.1252   
[3] LC_MONETARY=English_United States.1252 LC_NUMERIC=C                          
[5] LC_TIME=English_United States.1252    

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

loaded via a namespace (and not attached):
 [1] httr_1.3.1      compiler_3.5.1  R6_2.3.0        tools_3.5.1    
 [5] withr_2.1.2     curl_3.2        yaml_2.1.14     memoise_1.1.0  
 [9] digest_0.6.18   packrat_0.4.8-1 devtools_1.13.6

Thanks for your help!

[eddelbuettel]

That is a devtools bug. Or a PBKAC.

This is not functionality we document, recommend, use, or think highly of ourselves. Just grab it with curl or wget from https://cran.r-project.org/src/contrib/Archive/Rcpp/, ie https://cran.r-project.org/src/contrib/Archive/Rcpp/Rcpp_0.12.12.tar.gz, and install from that local file.

[eddelbuettel]

Also, maybe your error is in thinking you can randomly mix R versions and Rcpp versions. Maybe you can. Or maybe you cannot---in any event that is not how CRAN works. HEAD it is in repo speak. We actually work pretty hard to keep current versions clean and always installable. If those are not suited for you, well, sorry, then you need to adjust at your end.

[adamrobinson361]

Thanks @eddelbuettel - the use case is in the form of a packrat restore for an old project rather than devtools specific. That’s just a way to reproduce the error.

On your second point you could be right. 3.5.1 was used for convenience. I’ll test with the version it was developed in as recorded in packrat lock. Hopefully that will resolve the error.

Regards

Adam

[eddelbuettel]

I don't use packrat or devtools myself, so all I see from them ... are error messages like yours rather than (quite possibly numerous) successful uses.

I am surprised that it doesn't build. But as I explained, we work bloody hard (with literally thousand of tests of the package and also reverse depends tests) to make sure current versions build. Maybe R changed. In which case you packrat may be invalidated -- don't you want a similarly outdated R versions?

Carl does a lot of work in our Rocker Project to provide versioned R stacks. You should be able to work this out. But I remain adamant that it is not a bug in Rcpp as provided by this repo.

[adamrobinson361]

Yep understood - my initial thinking (having no experience with c++) was that an underlying c++ library had changed which was meaning It couldn’t build.

Re the need for packrat our usecase is that we require research projects to be reproducible over time in an organisation that hasnt yet adopted something like docker. Multiple r versions on windows is all we have.

Thanks for your help,

Adam

[eddelbuettel]

Gotcha. Besides packrat, you can also just adjust .libPath() and point to different (versioned, dated, ...) file system trees. But maybe I slowly back away from a discussion involving reproducible computing and Windows as a host os ...... as that is really not my corner of the world.

[kevinushey]

I thought that R removed Rf_pythag() and so newer releases of Rcpp no longer attempt to use it? If you tried to build older versions of Rcpp with newer R I'd expect to see this error.

…

On Sun, Oct 14, 2018, 10:18 AM Adam Robinson ***@***.***> wrote: Yep understood - my initial thinking (having no experience with c++) was that an underlying c++ library had changed which was meaning It couldn’t build. Re the need for packrat our usecase is that we require research projects to be reproducible over time in an organisation that hasnt yet adopted something like docker. Multiple r versions on windows is all we have. Thanks for your help, Adam — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#915 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB4pBiLj-z6cxzJ8oMoaXkBnpwtb-Hj6ks5uk3HJgaJpZM4XbMyF> .

[eddelbuettel]

And I admit I am woozy on the details but wasn't that even for r-devel? Well, maybe r-devel at the time which is (by now) of course r-release. But as @kevinushey says, you'd need something like the backports package (forget its exact name) also filling in for header changes. Not sure I call that a worthwhile endeavour.

In short, your restoration project worked exactly as planned but you may have jumped to the wrong conclusion. (Which happens to me multiple times a day too, so don't feel singled out...)

[adamrobinson361]

Successful build on 3.4.2 so all sorted. Thanks @kevinushey for the info on this been removed from R 3.5.1 - all makes sense now.

Thanks @eddelbuettel for the info too - illustrates the importance of environment management!