Hello Eljay,
> I am surprised that DSO C (RPC) does not have the typeinfo defined.
Yes this is indeed a mystery. I do not see any difference between DSO
B and DSO C in terms of how they throw a TEventHandle<EventBody>
object.
I tried adding the dummy instantiation routine to both DSO C as well
as RPC main. This is a great idea. Surprisingly, the symbols still
show up undefined. I'll keep at it today to see if I can find another
way to get the compiler to emit weak vs undefined symbols.
Thanks again for all the helpful advice.
Regards,
Dallas
On Wed, May 19, 2010 at 7:03 AM, John (Eljay) Love-Jensen
<eljay@xxxxxxxxx> wrote:
> Hi Dallas,
>
>> If DSO C is throwing this exception but it's symbol is undefined,
>> could that be the problem?
>
> I am surprised that DSO C (RPC) does not have the typeinfo defined.
>
> Look at the *.o files for the DSO C (RPC) to see which one(s) have those
> undefined symbols.
>
> Then look carefully at the .cpp code for the .o file(s) to see what it is
> doing. Perhaps the code is only dealing with pointers or references.
> Perhaps the code has forward declarations of those things.
>
>> Any advice on how I can do this [kluge]? This problem was happening even
>> when I was using inline / auto template instantiation vs. explicit.
>
> In your main application:
>
> extern void DummyRoutineToForceInstantiateTypeinfo(int i);
> void DummyRoutineToForceInstantiateTypeinfo(int i)
> {
> if (i == 1) throw Execution::EventBody();
> if (i == 2) throw DOCF::UserExceptionBody();
> if (i == 3) throw Execution::TEventHandle<Execution::EventBody>();
> if (i == 4) throw Execution::TEventHandle<DOCF::UserExceptionBody>();
> }
>
> I think that will cause the compiler to emit the desired typeinfo into your
> main executable.
>
>> Thanks again for all the help!
>
> No problem. :-) Namaste.
>
> Sincerely,
> --Eljay
>
>
