[omniORB] question regarding ORB initialization in DLLs and some general problems

[Andrew Buza]

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.
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)?

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.

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.

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?

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20090619/cf79beee/attachment.htm