terminate called after throwing an exception from a shared library

[Dallas Clement]

Hello,

As a follow up to this question, would someone kindly explain to me
the difference between these two lines that are output by the nm
utility?

000000000061ef10 V typeinfo for Execution::TEventHandle<Execution::EventBody>
0000000000418f20 V typeinfo name for
Execution::TEventHandle<Execution::EventBody>

In other words how does "typeinfo for" differ from "typeinfo name for"?

Lastly, if I have defined a type (TEventHandle) in one DSO (A) and
that type is referred to in another DSO (B) as well as a program
executable that links with both DSOs, I am assuming that DSO B and the
the executable should have the following in their nm output:

U typeinfo for Execution::TEventHandle<Execution::EventBody>

I'm assuming this because the type is only defined in DSO A and should
be undefined in DSO B as well as the executable.  Is this
understanding correct?

Thanks,
Dallas

On Sat, May 15, 2010 at 9:37 AM, Dallas Clement
<dallas.a.clement@gmail.com> wrote:
> Hi Matthias,
>
> Thanks so much for the help.  You were spot on.  My TEventHandle
> template class had been instantiated in each of the shared libraries
> as well as the program executable.  Explicit instantiation did the
> trick.
>
> Thanks again!
>
> Dallas
>
> On Sat, May 15, 2010 at 5:09 AM, Matthias Kretz
> <kretz@fias.uni-frankfurt.de> wrote:
>> Hi,
>>
>> On Saturday 15 May 2010 06:28:58 Dallas Clement wrote:
>>> terminate called after throwing an instance of
>>> 'Execution::TEventHandle<Execution::EventBody>'
>>
>> I guess there is a local symbol of this type in both lib B and the executable.
>> As it happens often with templates you define Execution::TEventHandle only in
>> a header of lib A and the specialization
>> Execution::TEventHandle<Execution::EventBody> then gets instantiated in lib B
>> and the executable.
>>
>> Check your libs and executable with "nm -C" for (I think) typeinfo for
>> Execution::TEventHandle<Execution::EventBody>
>>
>> If this symbol is only defined in one DSO and undefined in the others it
>> should work. Else they use their own local symbol and thus seemingly a
>> different type.
>>
>> You can fix this issue by doing an explicit specialization in lib A and moving
>> at least one function of TEventHandle out of the header into a .cpp file of
>> lib A. (AFAIR -- it's been a long time since I messed with errors of this
>> kind.)
>>
>> Regards,
>>        Matthias
>>
>>
>