Re: [eigen] visibility of classes/dynamic_cast

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

Hi,

makes sense to me, and I would go as the gnu stl, i.e., always put the
visibility to "default" without an additional option.

gael

On Fri, Jun 25, 2010 at 11:08 AM, Benjamin Schindler
<bschindler@xxxxxxxxxxx> wrote:
> Hi
>
> I just discovered a rather nasty problem which affects both eigen2 and
> eigen3.
> When I compile my code using -fvisiblilty=hidden (which is recommended
> nowadays on linux), symbols which aren't marked as visible are hidden.
> This of course means, Eigen types are hidden.
>
> Now lets say we have 2 dso's, and I have a class like this:
>
> template<typename T>
> class MyVector: public AbstractData
> {
>    const std::type_info& getType() const { return typeid(T); }
> };
>
> I instantiate this template class with Eigen::Vector3f in both dso's.
> Lets look at the following use case:
>
> - dso 1 creates a MyVector<Eigen::Vector3f> *vector = new
> MyVector<Eigen::Vector3f>();
>
> - dso 2 gets the pointer, but in form of an AbstractData pointer. It
> will do this now:
>
> if(ptr->getType() == typeid(Eigen::Vector3f))
>  cout << "Halleluja" << endl;
>
> The comparison here will fail in dso2 and I won't output anything. Why
> is that so?
>
> The templates get instantiated in each dso, and therewith the typeinfo
> objects, which are hidden. Since gcc-3, typeinfo objects are compared by
> address for speed reasons (see here: http://gcc.gnu.org/faq.html#dso).
> The comparison of course fails because the type_info objects are
> different. The solution is to export the template classes using
> __attribute__((visibility("default"))).
> the stl implementation of gcc solves this by doing that:
>
> _GLIBCXX_BEGIN_NAMESPACE(std)
>
> which expands to
>
> namespace std __attribute__ ((__visibility__ ("default"))) {
>
> I have (on a rather older release, a built-in copy of Eigen in our
> software) tested something similar. I attached the diff for a sample
> implementation and it solved my issues.
> For a comparison, stl always exports the symbols to make sure things
> always work. In my implementation let it up to the user to decide that
> as this use case is rather rare. But may be you should throw in your
> weight here
>
> What's your opinion on this?
>
> Cheers
> Benjamin
>