I've tried compiling with the stand gcc that comes with centos6.10 and this is what I get. Similar error.
R CMD INSTALL -d /share/apps/R/4.0.0/plugin/miniCRAN/src/contrib/Rcpp_1.0.4.6.tar.gz processing '/share/apps/R/4.0.0/plugin/miniCRAN/src/contrib/Rcpp_1.0.4.6.tar.gz' a file * installing to library '/share/apps/R/4.0.0/plugin' * build_help_types= * DBG: 'R CMD INSTALL' now doing do_install() * created lock directory '/share/apps/R/4.0.0/plugin/00LOCK-Rcpp' * installing *source* package 'Rcpp' ... ** package 'Rcpp' successfully unpacked and MD5 sums checked ** backing up earlier installation ** using staged installation ** libs about to run R CMD SHLIB -o Rcpp.so api.cpp attributes.cpp barrier.cpp date.cpp module.cpp rcpp_init.cpp gcc -m64 -I"/share/apps/R/4.0.0/lib64/R/include" -DNDEBUG -I../inst/include/ -I/usr/local/include -fpic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -m64 -mtune=generic -c api.cpp -o api.o gcc -m64 -I"/share/apps/R/4.0.0/lib64/R/include" -DNDEBUG -I../inst/include/ -I/usr/local/include -fpic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -m64 -mtune=generic -c attributes.cpp -o attributes.o gcc -m64 -I"/share/apps/R/4.0.0/lib64/R/include" -DNDEBUG -I../inst/include/ -I/usr/local/include -fpic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -m64 -mtune=generic -c barrier.cpp -o barrier.o gcc -m64 -I"/share/apps/R/4.0.0/lib64/R/include" -DNDEBUG -I../inst/include/ -I/usr/local/include -fpic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -m64 -mtune=generic -c date.cpp -o date.o gcc -m64 -I"/share/apps/R/4.0.0/lib64/R/include" -DNDEBUG -I../inst/include/ -I/usr/local/include -fpic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -m64 -mtune=generic -c module.cpp -o module.o gcc -m64 -I"/share/apps/R/4.0.0/lib64/R/include" -DNDEBUG -I../inst/include/ -I/usr/local/include -fpic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -m64 -mtune=generic -c rcpp_init.cpp -o rcpp_init.o gcc -m64 -shared -L/share/apps/update/lib -o Rcpp.so api.o attributes.o barrier.o date.o module.o rcpp_init.o installing to /share/apps/R/4.0.0/plugin/00LOCK-Rcpp/00new/Rcpp/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 Error: package or namespace load failed for 'Rcpp' in dyn.load(file, DLLpath = DLLpath, ...): unable to load shared object '/share/apps/R/4.0.0/plugin/00LOCK-Rcpp/00new/Rcpp/libs/Rcpp.so': /share/apps/R/4.0.0/plugin/00LOCK-Rcpp/00new/Rcpp/libs/Rcpp.so: undefined symbol: _ZTISo Error: loading failed Execution halted ERROR: loading failed * removing '/share/apps/R/4.0.0/plugin/Rcpp' * restoring previous '/share/apps/R/4.0.0/plugin/Rcpp' -----Original Message----- From: Dirk Eddelbuettel [mailto:e...@debian.org] Sent: Thursday, June 11, 2020 12:02 PM To: Kevin Ushey <kevinus...@gmail.com> Cc: Dirk Eddelbuettel <e...@debian.org>; Fuhriman, Nathanael [US] (IS) (Contr) <nate.fuhri...@ngc.com>; rcpp-devel@lists.r-forge.r-project.org Subject: EXT :Re: [Rcpp-devel] Install failure undefined symbol On 11 June 2020 at 10:29, Kevin Ushey wrote: | The most likely cause here is that, even though Rcpp is being compiled | with gcc 9.2.0, an older version of libstdc++ is being found and used | at runtime, and that version of the libstdc++ library doesn't provide | the requested symbol (_ZTVN10__cxxabiv120__si_class_type_infoE). | | Best guess: LD_LIBRARY_PATH should normally be set as an environment | variable, not a Make variable, so setting this: | | LD_LIBRARY_PATH=/share/apps/gcc/9.2.0/lib:/share/apps/gcc/9.2.0/lib64: | /opt/openmpi/lib:/share/apps/update/lib:/opt/python/lib | | in your Makeconf won't help to ensure that the correct version of | libstdc++ is loaded at runtime. | | (It should also be possible to tell gcc to enforce the usage of an | alternate C++ standard library, but I can't recall exactly how that's | done and have thus far failed to re-divine it from a quick skim of the | gcc documentation.) Spot on. And while it's been a while, the _particular_ wisdom of that RH supplied compiler setup also _required_ sourcing of a shell snippet to set all appropriate values: PATH, LD_LIBRARY_PATH, ... (Astonishing, to say the least, to me that a distribution vendor cannot integrate the very toolkit it provides so that it is already turned on when you open a shaell. But as I said, I suspect the target market are sysadmins and CTOs not people trying to get work done ...) Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org _______________________________________________ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
