I'm not sure if this is related, but there is one issue that needs to be
addressed a link time for object files that are generated from C++ code.
In C++ it is permissible to include definitions (not just declarations) in
header files. This means more that one object file may contain a definition
for the same function. The standard does not require linkers to check that
the definitions are consistent. The way this typically works (the tricks
vary by OS) is that the definitions are declared "weak," meaning they
do not lead to "multiple def" error messages. The linker simply deletes any
extra weak defs. Without this the common convention of placing both
defs and declarations in C++ header files (esp. when templates are
used) would not work.
Dominick
On Mon, Oct 7, 2013 at 12:18 PM, Martyn Plummer <plumm...@iarc.fr> wrote:
> Yes, on reflection it's an ABI problem on Linux (use of PIC code in
> shared libraries means that any symbol can be interposed). Using
> namespaces isn't really the answer because that's an API issue. I think
> what you really need to do is control the visibility of your classes and
> functions so that everything is hidden except for the entry points you
> call from R (Writing R Extensions section 6.15). This should stop the
> symbol collision because hidden functions are resolved inside the shared
> object instead of going through a lookup table that can be overwritten
> by someone else's package.
>
> Martyn
>
>
>
> On Fri, 2013-10-04 at 15:05 -0400, Duncan Murdoch wrote:
> > I have now got two "solutions" to this. The rgl version currently on
> > CRAN does a simple rename to avoid the name clash. A later version,
> > still only on R-forge, puts most objects into a namespace called "rgl".
> > (The old code had two small namespaces "gui" and "lib"; they are gone
> now.)
> >
> > I am not yet confident that the current version with namespaces will
> > compile on all platforms; it seems much more fragile this way, with
> > errors showing up on Linux that were not errors on Windows. (E.g.
> > sometimes I included a header with declarations in the rgl namespace
> > followed by system header files, and the latter acted differently than
> > they did when placed before the rgl header file, apparently declaring
> > the system functions to be in a new anonymous namespace.)
> >
> > rgl also includes some C code from the gl2ps project and some C++ code
> > from FTGL; I didn't put those into the rgl namespace. So there are
> > still possibilities for clashes if anyone else uses those.
> >
> > I'm still surprised that anything with plugins works on Unix-alike
> > systems with such bizarre linking rules. This is one of those few cases
> > where the Windows design seems clearly superior.
> >
> > Duncan Murdoch
> >
> >
> > On 02/10/2013 10:50 AM, Duncan Murdoch wrote:
> > > I've had reports lately about segfaults in the rgl package. I've only
> > > been able to reproduce these on Linux. I am not so familiar with C++
> > > details, so I have a couple of questions way down below. But first some
> > > background info.
> > >
> > > One recipe to recreate the crash works with a new version 5.0-1 of
> the
> > > mixOmics package:
> > >
> > > > library(mixOmics)
> > > > example(pca)
> > >
> > > This crashes with messages like this:
> > >
> > > Program received signal SIGSEGV, Segmentation fault.
> > > 0x00007ffff28aafd9 in __exchange_and_add (__mem=0x7f7fffff7f7ffff7,
> > > __val=<optimized out>) at /usr/include/c++/4.7/ext/atomicity.h:48
> > > 48 { return __atomic_fetch_add(__mem, __val, __ATOMIC_ACQ_REL);
> }
> > >
> > > The call stack ends with this:
> > >
> > > #0 0x00007ffff28aafd9 in __exchange_and_add (__mem=0x7f7fffff7f7ffff7,
> > > __val=<optimized out>) at /usr/include/c++/4.7/ext/atomicity.h:48
> > > #1 __exchange_and_add_dispatch (__mem=0x7f7fffff7f7ffff7,
> > > __val=<optimized out>) at /usr/include/c++/4.7/ext/atomicity.h:81
> > > #2 _M_dispose (__a=..., this=0x7f7fffff7f7fffe7)
> > > at /usr/include/c++/4.7/bits/basic_string.h:242
> > > #3 ~basic_string (this=0x15f8770, __in_chrg=<optimized out>)
> > > at /usr/include/c++/4.7/bits/basic_string.h:536
> > > #4 Shape::~Shape (this=0x15f8760, __in_chrg=<optimized out>) at
> > > Shape.cpp:13
> > > #5 0x00007ffff22df50b in ~Background (this=0x15f8760,
> > > __in_chrg=<optimized out>) at Background.hpp:15
> > > #6 Background::~Background (this=0x15f8760, __in_chrg=<optimized out>)
> > > at Background.hpp:15
> > >
> > > Up to entry #4 this all looks normal. If I go into that stack frame, I
> > > see this:
> > >
> > >
> > > (gdb) up
> > > #4 Shape::~Shape (this=0x15f8760, __in_chrg=<optimized out>) at
> > > Shape.cpp:13
> > > warning: Source file is more recent than executable.
> > > 13 blended(in_material.isTransparent())
> > > (gdb) p this
> > > $9 = (Shape * const) 0x15f8760
> > > (gdb) p *this
> > > $10 = {_vptr.Shape = 0x7ffff2d8e290, mName = 6, mType = {
> > > static npos = <optimized out>,
> > > _M_dataplus = {<std::allocator<char>> =
> > > {<__gnu_cxx::new_allocator<char>> =
> > > {<No data fields>}, <No data fields>},
> > > _M_p = 0x7f7fffff7f7fffff <Address 0x7f7fffff7f7fffff out of
> > > bounds>}},
> > > mShapeColor = {mRed = -1.4044474254567505e+306,
> > > mGreen = -1.4044477603031902e+306, mBlue = 4.24399170841135e-314,
> > > mTransparent = 0}, mSpecularReflectivity = 0.0078125,
> > > mSpecularSize = 1065353216, mDiffuseReflectivity =
> 0.007812501848093234,
> > > mAmbientReflectivity = 0}
> > >
> > > The things displayed in *this are all wrong. Those field names come
> > > from the Shape object in the igraph package, not the Shape object in
> the
> > > rgl package. The mixOmics package uses both.
> > >
> > > My questions:
> > >
> > > - Has my code somehow got mixed up with the igraph code, so I really do
> > > have a call out to igraph's Shape::~Shape instead of rgl's
> > > Shape::~Shape, or is this just bad info being given to me by gdb?
> > >
> > > - If I really do have calls to the wrong destructor in there, how do I
> > > avoid this?
> > >
> > > Duncan Murdoch
> >
> > ______________________________________________
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> -----------------------------------------------------------------------
> This message and its attachments are strictly confidenti...{{dropped:8}}
>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
