Re: [eigen] visibility of classes/dynamic_cast

[Benjamin Schindler <bschindler@xxxxxxxxxxx>]

That's exactly why I asked initially. May be we should find out why stl
does it the way it does it...

Cheers
Benjamin

On 25.06.2010 15:15, Benoit Jacob wrote:
> 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
>>>>
>>>
>>>
>>
>>
>>
>>
> 
>