On 20-08-18 17:59, Iñaki Ucar wrote:
El lun., 20 ago. 2018 a las 16:18, Jan van der Laan
(<rh...@eoos.dds.nl>) escribió:
pkg2 compiles a shared library using pkg1's headers, but it does not
link against libpkg1.so (in general, this is not possible in R). So
both libpkg2.so and libpkg1.so define two copies of the same types,
Foo and FooBar. pkg2 allocates FooBar from libpkg1.so and then
dynamically casts it as FooBar from libpkg2.so. This is why clang
complains. It has to do with how RTTI comparisons are done across
dynamic objects (see, e.g.,
https://whatofhow.wordpress.com/2015/03/17/odr-rtti-dso/).
This is roughly what I suspected. However, if I understand that article
correctly problems should only occur with clang (which I am using;
didn't mention that) and not with g++. However, the problems also occur
with g++
(https://www.stats.ox.ac.uk/pub/bdr/memtests/gcc-UBSAN/ldat/ldat-Ex.Rout).
I don't know, maybe things have changed in recent versions of gcc.
I'd say that these errors can be safely ignored, because types are
exactly the same. Anyway, shouldn't it be easier to export get_foobar
in pkg1?
Don't know how easy it is to convince the CRAN members to ignore the
warnings. Of course, in this simple case, it is easier to define
get_foobar in pkg1, but in the general case, for performance reasons, I
would like to be able to access FooBar from other packages from c++ code.
I've just submitted a PR to your repo that fixes the issue:
https://github.com/djvanderlaan/lvec_ubsan/pull/1
Copy&paste of the explanation there, for the interest of this list:
Instead of using useDynLib in the NAMESPACE, this patch loads the
library using library.dynam in .onLoad. In this way, we can take
advantage of library.dynam's dots, which are mapped into the
subsequent dyn.load call. This call has local=TRUE by default, i.e.,
dlopen is called with the RTLD_LOCALattribute. Instead, local=FALSE
sets RTLD_GLOBAL, which makes type_info from pkg1 available globally,
and thus the RTTI error goes away.
OK, this seems to fix it. Not sure if the CRAN people like it when I
register my symbols globally as this could bite other packages with the
same symbol names. If I understand correctly; I am trying to read in on
this stuff :-S
Tomorrow I will check with lvec and ldat.
Thanks.
Jan
Iñaki
Thanks for the response.
Jan
Iñaki
So, help!?
Jan
_______________________________________________
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
_______________________________________________
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
