[omniORB] Symbol conflicts on Mac OS X

[Ashish Kumar Sharma]

Skipped content of type multipart/alternative-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 1523 bytes
Desc: image001.gif
Url : Loading Image...

[Thomas Lockhart]

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

[Ashish Kumar Sharma]

Thomas,

Post by Thomas Lockhart
I wouldn't expect either omniORB *or* Mico to be happy with another

ORB

Post by Thomas Lockhart
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:***@fourpalms.org]
Sent: Thursday, March 13, 2008 12:48 AM
To: Ashish Kumar Sharma
Cc: omniorb-***@omniorb-support.com
Subject: Re: [omniORB] Symbol conflicts on Mac OS X

Post by Thomas Lockhart
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