[omniORB] Symbol conflicts on Mac OS X

[Ashish Kumar Sharma]

Thomas,

> I wouldn't expect either omniORB *or* Mico to be happy with another
ORB 
> implementation in the same executable. Why use both in the same 
> application?

My application is not linking to the ORB libraries directly, only the
application's dependencies (X.a and Y.dylib) link to ORB libraries. So I
don't get any compilation or linking errors when I build my application.
Even at run time, references to all other symbols (other than those
listed below) are resolved correctly by the dynamic link editor. This
indirect dependency on both mico and omni ORB is something we have to
live with (atleast for sometime).

Infact this used to work pefectly fine when X.a was using 4.0.1 version
of omni ORB libraries. It's only when we moved X.a to later version of
omni (4.1.0), we encountered runtime crashes.

It seems that the conflicting symbols
(CORBA::DefaultRefCountBase::_add_ref &
CORBA::DefaultRefCountBase::_remove_ref) were not available in omni
version 4.0.1 so my application used to work fine. I am not sure if this
is a problem with gcc on Mac OS X but this occurs for these symbols
alone... so for now, I am completely off the track..

Regards
Ashish

-----Original Message-----
From: Thomas Lockhart [mailto:lockhart at fourpalms.org] 
Sent: Thursday, March 13, 2008 12:48 AM
To: Ashish Kumar Sharma
Cc: omniorb-list at omniorb-support.com
Subject: Re: [omniORB] Symbol conflicts on Mac OS X

>  My C++ application (on Mac OS X version 10.4.11) makes use of omni
>  ORB (4.1.0) and Mico (2.3.12)  shared libraries.  Omni ORB libraries
>  are dependencies of a static library(X.a) linked into the application
>  and mico libraries are dependencies of a dynamically loaded shared
>  library(Y.dylib).

I wouldn't expect either omniORB *or* Mico to be happy with another ORB 
implementation in the same executable. Why use both in the same 
application? In my (simple) test cases one can compile against one or 
the other with fairly minor changes in #include statements to get the 
right header files, and you can use the same source code for both by 
testing for which ORB is being compiled using an #ifdef.

hth

                          - Tom