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
