Re: [eigen] visibility of classes/dynamic_cast

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