installation/compilation fails in R version 3.6.0

[johebll]

Hello, i have issues with the installation/compilation of RcppArmadillo, when attempting to install it. Both, from CRAN or via BioCon, with the same error:

Bioconductor version 3.10 (BiocManager 1.30.10), R 3.6.0 (2019-04-26)
Installing package(s) RcppArmadillo
trying URL https://cran.rstudio.com/src/contrib/RcppArmadillo_0.10.1.0.0.tar.gz
Content type application/x-gzip' length 1643776 bytes (1.6 MB)

downloaded 1.6 MB

* installing *source* package ‘RcppArmadillo’ ...
** package ‘RcppArmadillo’ successfully unpacked and MD5 sums checked
** using staged installation
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ -m64 -std=gnu++11 accepts -g... yes
checking how to run the C++ preprocessor... g++ -m64 -std=gnu++11 -E
checking whether we are using the GNU C++ compiler... (cached) yes
checking whether g++ -m64 -std=gnu++11 accepts -g... (cached) yes
checking whether we have a suitable tempdir... /tmp
checking whether R CMD SHLIB can already compile programs using OpenMP... yes
checking LAPACK_LIBS... R-supplied partial LAPACK found
configure: WARNING: Some complex-valued LAPACK functions may not be available
configure: creating ./config.status
config.status: creating inst/include/RcppArmadilloConfigGenerated.h
config.status: creating src/Makevars
** libs
g++ -m64 -std=gnu++11 -I"/usr/include/R" -DNDEBUG  -I"/usr/lib64/R/library/Rcpp/include" -I/usr/local/include -I../inst/include  -fpic  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic  -c RcppArmadillo.cpp -o RcppArmadillo.o
RcppArmadillo.cpp:26:40: error: redeclaration ‘arma::arma_version::major’ differs in ‘constexpr’
 const unsigned int arma::arma_version::major;
                                        ^
In file included from ../inst/include/armadillo:91:0,
                 from ../inst/include/RcppArmadilloForward.h:49,
                 from ../inst/include/RcppArmadillo.h:31,
                 from RcppArmadillo.cpp:22:
../inst/include/armadillo_bits/arma_version.hpp:31:33: error: from previous declaration ‘arma::arma_version::major’
   static constexpr unsigned int major = ARMA_VERSION_MAJOR;
                                 ^
RcppArmadillo.cpp:26:40: error: declaration of ‘constexpr const unsigned int arma::arma_version::major’ outside of class is not definition [-fpermissive]
 const unsigned int arma::arma_version::major;
                                        ^
RcppArmadillo.cpp:27:40: error: redeclaration ‘arma::arma_version::minor’ differs in ‘constexpr’
 const unsigned int arma::arma_version::minor;
                                        ^
In file included from ../inst/include/armadillo:91:0,
                 from ../inst/include/RcppArmadilloForward.h:49,
                 from ../inst/include/RcppArmadillo.h:31,
                 from RcppArmadillo.cpp:22:
../inst/include/armadillo_bits/arma_version.hpp:32:33: error: from previous declaration ‘arma::arma_version::minor’
   static constexpr unsigned int minor = ARMA_VERSION_MINOR;
                                 ^
RcppArmadillo.cpp:27:40: error: declaration of ‘constexpr const unsigned int arma::arma_version::minor’ outside of class is not definition [-fpermissive]
 const unsigned int arma::arma_version::minor;
                                        ^
RcppArmadillo.cpp:28:40: error: redeclaration ‘arma::arma_version::patch’ differs in ‘constexpr’
 const unsigned int arma::arma_version::patch;
                                        ^
In file included from ../inst/include/armadillo:91:0,
                 from ../inst/include/RcppArmadilloForward.h:49,
                 from ../inst/include/RcppArmadillo.h:31,
                 from RcppArmadillo.cpp:22:
../inst/include/armadillo_bits/arma_version.hpp:33:33: error: from previous declaration ‘arma::arma_version::patch’
   static constexpr unsigned int patch = ARMA_VERSION_PATCH;
                                 ^
RcppArmadillo.cpp:28:40: error: declaration of ‘constexpr const unsigned int arma::arma_version::patch’ outside of class is not definition [-fpermissive]
 const unsigned int arma::arma_version::patch;
                                        ^
make: *** [RcppArmadillo.o] Error 1
ERROR: compilation failed for package ‘RcppArmadillo’
* removing ‘/usr/lib64/R/library/RcppArmadillo’
* restoring previous ‘/usr/lib64/R/library/RcppArmadillo’

My versions are:

Platform: x86_64-redhat-linux-gnu (64-bit)
Running under: CentOS Linux 7 (Core)

Matrix products: default
BLAS/LAPACK: /usr/lib64/R/lib/libRblas.so

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C              
 [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8    
 [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8   
 [7] LC_PAPER=en_US.UTF-8       LC_NAME=C                 
 [9] LC_ADDRESS=C               LC_TELEPHONE=C            
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C       

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

loaded via a namespace (and not attached):
[1] BiocManager_1.30.10 compiler_3.6.0      tools_3.6.0        

Bioconductor version '3.10'

  * 1 packages out-of-date
  * 0 packages too new

create a valid installation with

  BiocManager::install("RcppArmadillo", update = TRUE, ask = FALSE)

more details: BiocManager::valid()$too_new, BiocManager::valid()$out_of_date

Warning message:
1 packages out-of-date; 0 packages too new 

Is there any thing i can adjust to make it work?

[eddelbuettel]

Strange that this did not upset any of the (700+) test builds, twice, or any of the builds at CRAN. The three lines of which the first is listed above in the error are simply redundant, I will remove them in the next version. You could edit this by hand:

diff --git a/src/RcppArmadillo.cpp b/src/RcppArmadillo.cpp
index 831e6cc..7ed0f6d 100644
--- a/src/RcppArmadillo.cpp
+++ b/src/RcppArmadillo.cpp
@@ -23,10 +23,6 @@

 using namespace Rcpp;

-const unsigned int arma::arma_version::major;
-const unsigned int arma::arma_version::minor;
-const unsigned int arma::arma_version::patch;
-
 //' Report the version of Armadillo 
 //' 
 //' @details The version is defined by Armadillo in the header \code{arma_version.hpp}.
edd@rob:~/git/rcpparmadillo(master)$ 

You could also use an older version.

[eddelbuettel]

I have now fixed this in a commit (plus a minor follow-up clean-up commit for the same source) and placed a new minor revision 0.10.1.0.1 of the package into the Rcpp drat repo so by doing

 install.packages("RcppArmadillo", repos="https://rcppcore.github.io/drat")

you get that fixed version that should not upset your (older, I supposed) compiler. Full log below.

edd@rob:~$ Rscript -e 'install.packages("RcppArmadillo", repos="https://rcppcore.github.io/drat")'
Installing package into ‘/usr/local/lib/R/site-library’
(as ‘lib’ is unspecified)
trying URL 'https://rcppcore.github.io/drat/src/contrib/RcppArmadillo_0.10.1.0.1.tar.gz'
Content type 'application/gzip' length 1552600 bytes (1.5 MB)
==================================================
downloaded 1.5 MB

* installing *source* package ‘RcppArmadillo’ ...
** using staged installation
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether ccache g++-10 accepts -g... yes
checking how to run the C++ preprocessor... ccache g++-10 -E
checking whether we are using the GNU C++ compiler... (cached) yes
checking whether ccache g++-10 accepts -g... (cached) yes
checking whether we have a suitable tempdir... /tmp
checking whether R CMD SHLIB can already compile programs using OpenMP... yes
checking LAPACK_LIBS... system LAPACK found
configure: creating ./config.status
config.status: creating inst/include/RcppArmadilloConfigGenerated.h
config.status: creating src/Makevars
** libs
ccache g++-10  -std=gnu++11 -I"/usr/share/R/include" -DNDEBUG  -I'/usr/local/lib/R/site-library/Rcpp/include'   -I../inst/include  -fpic  -g -O3 -Wall -pipe  -Wno-ignored-attributes -Wno-unused -c RcppArmadillo.cpp -o RcppArmadillo.o
ccache g++-10  -std=gnu++11 -I"/usr/share/R/include" -DNDEBUG  -I'/usr/local/lib/R/site-library/Rcpp/include'   -I../inst/include  -fpic  -g -O3 -Wall -pipe  -Wno-ignored-attributes -Wno-unused -c RcppExports.cpp -o RcppExports.o
ccache g++-10  -std=gnu++11 -I"/usr/share/R/include" -DNDEBUG  -I'/usr/local/lib/R/site-library/Rcpp/include'   -I../inst/include  -fpic  -g -O3 -Wall -pipe  -Wno-ignored-attributes -Wno-unused -c fastLm.cpp -o fastLm.o
ccache g++-10 -std=gnu++11 -Wl,-S -shared -L/usr/lib/R/lib -Wl,-Bsymbolic-functions -Wl,-z,relro -o RcppArmadillo.so RcppArmadillo.o RcppExports.o fastLm.o -llapack -lblas -lgfortran -lm -lquadmath -L/usr/lib/R/lib -lR
installing to /usr/local/lib/R/site-library/00LOCK-RcppArmadillo/00new/RcppArmadillo/libs
** R
** inst
** byte-compile and prepare package for lazy loading
** help
*** installing help indices
** building package indices
** installing vignettes
** testing if installed package can be loaded from temporary location
** checking absolute paths in shared objects and dynamic libraries
** testing if installed package can be loaded from final location
** testing if installed package keeps a record of temporary installation path
* DONE (RcppArmadillo)

The downloaded source packages are in
        ‘/tmp/RtmpbNVVeQ/downloaded_packages’
edd@rob:~$ 

[johebll]

Hello Dirk,

thank you a ton for helping so super quick!

Strange that this did not upset any of the (700+) test builds

Exactly, i also stumbled upon this when attempting to google it, with no substantial occurrences :-)

Your fix helped, it just worked for me! Thank you again.

[eddelbuettel]

Great. Remind me again what the compiler version on CentOS 7 is?

To me, and hindsight is 20/20 this was both a 'code nuisance' (I won't call it bug because it really just allocated three unused vars) which all other compilers appear to a) ignore and b) not warn about (which is odd, I do turn -Wall -pedantic and whatnot on). So I am inclined to point fingers at an older g++ version...

[conradsnicta]

CentOS 7 uses gcc 4.8, which is pretty ancient by now. While a vast majority of C++11 code is likely to work with gcc 4.8, support for C++11 in gcc 4.8 is buggy and/or incomplete, resulting in corner cases like this. The minimum recommended version of gcc is 5.4.

More recent versions of gcc can be used on CentOS 7 via Software Collections: https://www.softwarecollections.org/en/scls/rhscl/devtoolset-8/

CentOS 7 is overall quite old anyway, so it may be useful to upgrade to CentOS 8 at this stage. Full updates for RHEL 7 and CentOS 7 stopped on 2020-08-06.

[eddelbuettel]

I could have sworn it was a newer one than 4.8.* which is indeed "old". We had minimum compiler detection in the configure script too, I am surprised this passed it. Maybe it shouldn't have.

gcc/g++ 4.8.0 to 4.8.5 were released between 2013 and 2015. That is, to be frank, "dark ages" time. Sadly CentOS 7 is still pretty widely used -- but can be used with newer compilers too.

[johebll]

Hello Dirk,

sorry for being late. Can confirm what my predecessors already stated:

gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39)

We have gcc7 installed in parallel, but leave the OS standard as default, ironically for the sake of stability ;-) We are in general on 8, but have to keep this specific (complex) installation on 7 due to dependenicies... EOL CentOS 7: 30 June 2024 ;-) Thank you again!

[eddelbuettel]

Thanks for circling back. We still have an explicit test in configure.ac for an even older version (and it comes from many years ago) but the code got moved around and now the the 'do we have OpenMP or not' test dominates all. And, quite frankly, if I were to be hardnosed and imposed g++-5.* I suspect I would hear lots of complainst.

But we really do prefer proper C++11 now so a newer compiler may be a good idea. There are some supported 'developer tools' for RH/CentOS with newer compilers (but I can't recall the exact name). Keep that in mind--there are supported alternatives.

[pcarbo]

I can confirm the issue with the current version on CRAN, and that this solution works. (I have gcc 4.8.5.)

[eddelbuettel]

Peter, not sure if you follow the (low-volume) rcpp-devel list but I regularly drop updated 'micro' (i.e. not CRAN) releases of both Rcpp and RcppArmadillo into the RcppCore drat repo so

   R> install.packages("RcppArmadillo", repos="https://rcppcore.github.io/drat")

works and gets you 0.10.1.0.2. If you set the repo (and the drat package has easy helper functions, doing it manually works of course too), then update.packages() works the same way.

[pcarbo]

Thanks!

[detule]

Dirk - thanks for all your work.

We use RcppArmadillo in production - and are restricted to only being able to communicate with CRAN repos.

I noticed on the devel list that you mentioned an out-of-order release is not in the works. Any possibility to reconsider this? Our platform is relatively inflexible and turning on enhanced collections or otherwise upgrading the compiler are not really an option, unfortunately.

Thanks again for all your work.

[eddelbuettel]

We use RcppArmadillo in production

Somone needs to take better care of the infrastructure at your end. If you want current software from CRAN, use current compilers and tools just like CRAN (and many of us do):

If you are bound by old equipment you could at least test with it. I make CRAN releases available as pre-releases for everybody to look at. And I have made new releases with the fixes. All you need is a one-line addition to your configurations.

PS Someone even came via StackOverflow with an even more ridiciluous example of failing on a cloud instance with R 3.4.* (!!) from 2017: https://stackoverflow.com/questions/64674494/how-to-install-rcpparmadillo-in-aws-emr-version-5-29

Sorry, but that is still a no.

[detule]

Thanks Dirk:

Appreciate the quick response - sounds like the answer is no.

Your notes about best practices make sense - we'll look to decoupling from RcppArmadillo.

[eddelbuettel]

I never recommend vendoring because I think it is a really bad solution but you could embed an older version of (Rcpp)Armadillo. Then the maintenance burden is yours, you don't get updates or bug fixes but it may work on your 'historic' equipment.

Otherwise: wait for the next release, or, as I suggested multiple times now use RcppArmadillo 0.10.1.0.2 from the drat repo

[conradsnicta]

@detule - A new patch release of Armadillo is in the works, which should eventually be followed with a corresponding RcppArmadillo release.
Older releases are officially available from CRAN: https://cran.r-project.org/src/contrib/Archive/RcppArmadillo/
In your particular case, version 0.9.900.3.0 should work.

[detule]

@conradsnicta Appreciate the note.

On our end we have built [R] packages that link to the C++ resources provided by RcppArmadillo. As far as I know, base [R]'s install.packages does not have the facility to automatically reach into a CRAN Archive, even when one tries to limit to a desired version of RcppArmadillo via the "<=" operators in the appropriate fields of the DESCRIPTION fie.

Our users also range from very sophisticated to novice; for some instructions such as "install an older version of RcppArmadillo form a CRAN Archive" is more than sufficient - for others not so much.

Of course there are many package management options available out there - some more sophisticated that allow for more creative solutions + hosted repositories + package freezing, but our eco system is limited (further complicated by automated deployments to Rstudio Connect, etcetra).

At any rate - I also appreciate your position and where you are coming from.

[sclewis23]

Thanks for circling back. We still have an explicit test in configure.ac for an even older version (and it comes from many years ago) but the code got moved around and now the the 'do we have OpenMP or not' test dominates all. And, quite frankly, if I were to be hardnosed and imposed g++-5.* I suspect I would hear lots of complainst.

But we really do prefer proper C++11 now so a newer compiler may be a good idea. There are some supported 'developer tools' for RH/CentOS with newer compilers (but I can't recall the exact name). Keep that in mind--there are supported alternatives.

@eddelbuettel - I know this issue is resolved, but I had one related question: We are using Centos7 but are using devtoolset-8 (g++ (GCC) 8.3.1 20190311 (Red Hat 8.3.1-3) ), via Makevars.site file but when I try to install it still fails. I think because we are not over writing the OS gcc, just changing it via the Makevars.site it fails. Is it possible to use Makevar.site to select the compiler instead of just using the complier found at command line?

[eddelbuettel]

Two things:

• for devtools set you need to source a shell script snippet to have CC, CXX, ... set; I presume you have done that
• for R, everything happens from R and it uses its own Makefile snippet you can look at R.home("etc/Makeconf")

You need to ensure that variable in the latter reflect the updated values from the former. Maybe you need to add CXX11 alongside an existing CXX. It's been a while since I had the distinct "pleasure" of having to work on CentOS.

And I am going to lock this now. Everything that needed to be said about the non-bug (as far as CRAN is concerned) in RcppArmadillo has been said, and I provided an updated version for "exotic" systems such as CentOS. I don't get paid to support CentOS/RHEL, and get no benefit from it so I stop now.

For the rest there is the rcpp-devel mailing list where you may find other CentOS users.