Re: [eigen] visibility of classes/dynamic_cast

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

If we export our whole namespace, isn't it going to kill the benefit
of -fvisibility=hidden for Eigen-using libraries?

We're not like the STL, we instantiate many more templates.

Shouldn't we export only a few Eigen classes, namely Matrix, Array,
and a few others ?

Benoit

2010/6/25 Benjamin Schindler <bschindler@xxxxxxxxxxx>:
> Hi
>
> So I started implementing this. I have something which is pullable now
> in a branch here:
>
> https://bitbucket.org/bschindler/eigen-import
>
> Feel free to comment
>
> Cheers
> Benjamin
>
> I've run the test-suite. 4 failures, but it seems
> On 06/25/2010 02:03 PM, Gael Guennebaud wrote:
>> 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
>>>
>>
>>
>
>
>
>