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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx> 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 >> >> >
