Hi Andrew, The relevant code defining the constant is here:
https://github.com/RcppCore/RcppArmadillo/blob/66dcdb5e878b391cd44a8c2854898abd002272ed/inst/include/armadillo_bits/constants.hpp#L176 If I understand correctly, that is effectively defining static (global) values for a template class, so if that template class were instantiated in two different libraries, then you might see this issue. Indeed, if you inspect the shared objects built in your package: $ nm RcppPlanc.so | grep nan | c++filt 0000000000070a18 u guard variable for arma::Datum<double>::nan 0000000000070a20 u arma::Datum<double>::nan $ nm libnmflib.so | grep nan | c++filt 0000000000160f40 u guard variable for arma::Datum<double>::nan 0000000000160f10 u guard variable for arma::Datum<int>::nan 0000000000160f20 u guard variable for arma::Datum<unsigned int>::nan 0000000000160f38 u guard variable for arma::Datum<unsigned long long>::nan 0000000000160f68 u arma::Datum<double>::nan 0000000000160f48 u arma::Datum<int>::nan 0000000000160f50 u arma::Datum<unsigned int>::nan 0000000000160f60 u arma::Datum<unsigned long long>::nan you can see the two definitions for these objects. This also explains why combining everything into a single library would be a solution, as suggested by Serguei -- you'd then only have one instance of those symbols. For what it's worth, C++17 provides support for "static inline" constants as a way to avoid these issues. This is discussed a bit in https://en.cppreference.com/w/cpp/language/inline. If Armadillo (and hence RcppArmadillo) were updated to take advantage of these features when available, that might also alleviate the issue you're seeing. Best, Kevin On Wed, May 21, 2025 at 6:55 AM Dirk Eddelbuettel <e...@debian.org> wrote: > > > Andrew, > > On 21 May 2025 at 12:48, andrew--- via R-package-devel wrote: > | I'm currently having difficulty replicating an ODR violation that is being > raised by the gcc-asan check here: > https://www.stats.ox.ac.uk/pub/bdr/memtests/gcc-ASAN/RcppPlanc/00install.out. > Perhaps weirder, it seems to be triggered by an inclusion of > armadillo_bits/constants.hpp in both my shared object and the Rcpp binding > library-which seems like something that shouldn't be raising any issues. > | > | Dirk, you wouldn't happen to have seen this before? > > Sorry, have not. Could you possibly distill this out so that RcppPlanc is not > used, and possibly also avoid cmake. A minimally complete verifiable example > would be great as the log you point at is a little long. > > Cheers, Dirk > > -- > dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > > ______________________________________________ > R-package-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-package-devel ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
