[Rcpp-devel] EXT :Re: Install failure undefined symbol

[Fuhriman, Nathanael [US] (IS) (Contr)]

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:edd at debian.org] 
Sent: Thursday, June 11, 2020 12:02 PM
To: Kevin Ushey <kevinushey at gmail.com>
Cc: Dirk Eddelbuettel <edd at debian.org>; Fuhriman, Nathanael [US] (IS) (Contr) <nate.fuhriman at ngc.com>; rcpp-devel at 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 | edd at debian.org