I have multiple DLLs (used as extensions to a 3rd party application) that use omniORB and I'm having quite a bit of trouble getting everything working. I've read section 4.5.1 (ORB initialization) of the CORBA architecture spec, but I'm not sure what the correct way to initialize omniORB is when it's used by multiple DLLs loaded by the same process.<div>
<br></div><div>For instance, should each library call ORB_init or must it be done only once (and the resulting ORB_ptr exported to other dlls in some way)?</div><div><br></div><div>Right now my project is a mess. When linking to omniorb statically, ORB_init will cause an access violation in logiostream.cc:516 (a call to fputs), and when linked dynamically it will cause the same when calling delete[] in any CORBA sequence. If I move back to omniORB-4.1.0 I no longer have problems with initalization and destruction, but calling methods of *_vars passed across module boundaries will cause access violations in omni_mutex::lock. </div>
<div><br></div><div>I've made sure that everything is linking with the correct runtime library as mentioned in the wiki. I feel like I must be doing something fundamentally wrong, but I'm not sure exactly what that might be -- any suggestions would be welcome.</div>
<div><br></div><div>I'm using omniORB-4.1.3 (compiled with /Zc:wchar_t) and msvc 7.1.6030. The same projects are also built with msvc 8 and work fine. The application that loads my DLLs (Adobe InDesign) appears to be involved in (de)allocation in some way since one of its dlls appears in the call stack between the call to operator delete[] in my code and the implementation in ntdll.dll. Might this be the source of some of my problems?</div>
<div><br></div><div>Thanks for any help anyone can provide, even if it's just a pointer to some information or a better place for these sorts of questions.</div>