AW: [omniORB] Trouble with multiple ORB implementations...

[Hopfes, Harald]

Hi!

I had once an application that was dynamically linked to 2 different version
of libstdc++ 
(one version used by me and the compiler I use, the other used by another
dynamic library that we used)

The result was a crash a well. It seems that it is not possible to use 2
different versions of dynamic librarys at the same time in the same program.

Harald

> -----Ursprüngliche Nachricht-----
> Von: Gerke, Tom [mailto:tom.gerke@intel.com]
> Gesendet: Donnerstag, 12. September 2002 00:12
> An: 'omniorb-list@omniorb-support.com'
> Cc: Patel, Bhavin
> Betreff: [omniORB] Trouble with multiple ORB implementations...
> 
> 
> I am using OmniORB2 2.8 on RedHat Linux version 7.3.2.96-110. 
>  I am using
> gcc compiler version 2.96.
> 
> My application dynamically links with the OmniORB2 .so libraries.  My
> application also links with another .so library, let's call it library
> 'XXX'.  This 'XXX' library in turn utilizes its own ORB, let's call it
> 'ORB_XXX'.  (Library 'XXX' has been dynamically linked to 
> it's own set of
> 'ORB_XXX' .so libraries.)
> (NOTE: I believe that the other ORB is ORBacus 4.05, but I'm 
> not 100% sure.)
> 
> When I call a function inside library 'XXX', it calls its own
> CORBA::ORB_init() function, in its own 'ORB_XXX' .so library.  As this
> function continues with its processing, it somewhere deletes 
> a string object
> which in turn causes CORBA::string_free() to be called.  But, this
> CORBA::string_free() call is called in the OmniORB2 .so library.
> Why is this?  Does it have to do with both ORBs using the 
> "CORBA" namespace?
> If so, how would I resolve this?
> 
> It ends up core dumping in a call to pthread_mutex_lock().  I 
> imagined that
> this core dump was related to the fact that 
> CORBA::string_free() was called
> in the OmniORB2 .so library and not in the 'ORB_XXX' .so 
> library.  Do you
> think the core dump is related to this?
> 
> Finally, have you ever, or do you know anyone who has ever, had a
> configuration like this (i.e. 2 different dynamically loaded ORB
> implementations in the same application, functioning 
> independently of each
> other)?
>