[omniORB] omniDynamic280_rt now required?

[Sai-Lai Lo]

The short answer is yes on NT with MSVC++. There is a workaround though.

For reasons that I do not understand, the object code now contains
references to a handful of symbols that are in omniDynamic280_rt even if
there is no reference to the functions in that library!

I encountered the same problem when building omniORB280_rt.dll. The
workaround I came up with is to link into the DLL a dummy stub file 
(<top>/lib/omniORB2/orbcore/sharedlib/msvcdllstub.cc). There is no ill
effect because I'm certain that the functions defined in msvcdllstub.cc are
never called in omniORB280_rt.dll. The functions are not exported from the
DLL so they don't interfere with the real implementation in omniDynamic280_rt.

If you don't want to link omniDynamic280_rt.dll and you don't mind this
hack, copy <top>/lib/omniORB2/orbcore/sharedlib/msvcdllstub.cc and link it
with your executable. This is only useful if you do not use Any, TypeCode,
DSI, DII and all their friends in the dynamic interfaces.

I think the spurious symbol dependency is a bug in MSVC++ but I cannot find
a workaround to stop this from happening.

Sai-Lai


>>>>> Jason DeBettencourt writes:

> Using NT4.0 SP5, MSVC 6.0:
> I just rebuilt my code with the new 2.8.0 release, and
> came up with a bunch of unresolved symbols.

> unresolved external symbol "public: __thiscall
> CORBA::TypeCode_member::~TypeCode_member(void)"
> (??1TypeCode_member@CORBA@@QAE@XZ)

> I see that these symbols are in omniDynamic280_rt, is
> it now required to link the dynamic support even if
> I'm not using it?  

> My omniidl2 command line looks like this: 
> omniidl2 -t sm_svc.idl



-- 
Sai-Lai Lo                                   S.Lo@uk.research.att.com
AT&T Laboratories Cambridge           WWW:   http://www.uk.research.att.com 
24a Trumpington Street                Tel:   +44 1223 343000
Cambridge CB2 1QA                     Fax:   +44 1223 313542
ENGLAND