Re: [eigen] visibility of classes/dynamic_cast

[ Thread Index | Date Index | More Archives ]


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


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:
> 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:
> 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

Mail converted by MHonArc 2.6.19+