[omniORB] Problem using shared object implementations with omniORB 3.0.

[b.keeping@ic.ac.uk]

Hi,

This is probably a question just for the implementors...

I have run into a problem using version 3.0 which did not occur with
2.8, and which I'm not sure how to get round. I am working on Solaris
but I suspect the problem is not OS-specific.

I make extensive use of the approach described in my posting
http://www.uk.research.att.com/omniORB/archives/1999-01/0075.html
i.e. using dynamic loading to bring a CORBA server implementation
selected at runtime into the same process as the client. This posting
provoked no response at the time, so perhaps I'm the only one doing
this?! I'd certainly still like to know if there's a better way.

Anyway, this worked fine with 2.8, but with 3.0 I get a fatal
exception when I dynamically load, caused by the presence of static
objects defined in the .hh files. The exception is thrown in the
constructor of ProxyObjectFactory, which is called with the repository
Id of every interface used in the code. During dynamic loading, this
constructor is called for the second time with the same repoId, which
results in the exception.

Here is the stack trace for the first entry to the constructor for the
offending repoId, before the client program enters main():

=>[1] proxyObjectFactory::proxyObjectFactory(this = 0x18dd9c, repoId = 0x178590 "IDL:ICapeMILPSolverComponent:1.0"), line 63 in "proxyFactory.cc"
  [2] _pof_ICapeMILPSolverComponent::_pof_ICapeMILPSolverComponent(this = 0x18dd9c), line 147 in "ICapeMILPSolverComponent.hh"
  [3] __STATIC_CONSTRUCTOR(), line 131 in "ICapeMILPSolverComponentSK.cc"
  [4] _init(0x0, 0x189800, 0x0, 0x0, 0x1, 0x0), at 0x4781c

and here is the stack trace for the second call (which throws the exception):

=>[1] proxyObjectFactory::proxyObjectFactory(this = 0x18dd9c, repoId = 0x178590 "IDL:ICapeMILPSolverComponent:1.0"), line 63 in "proxyFactory.cc"
  [2] _pof_ICapeMILPSolverComponent::_pof_ICapeMILPSolverComponent(this = 0x18dd9c), line 147 in "ICapeMILPSolverComponent.hh"
  [3] __STATIC_CONSTRUCTOR(), line 131 in "ICapeMILPSolverComponentSK.cc"
  [4] _init(0x0, 0x4000, 0xffffffff, 0xef7ed838, 0xef7ed820, 0xeef31b8c), at 0xee3b642c
  [5] call_init(0xeeda03f4, 0x0, 0xef7ed818, 0xef7ed7f8, 0xee3b63d4, 0xeeda0448), at 0xef7ca5ac
  [6] dlmopen_lock(0xef7ed918, 0xefffef60, 0xeeda0198, 0xef7eea70, 0x1, 0xeeda03f4), at 0xef7cd9c4
  [7] loadsolver(type = 0x1697f4 "CPXMILPSOL", ok = 0xeffff07f "\xe8"), line 26 in "MILPexec.cxx"
  [8] MILPexec(cormilp = CLASS), line 56 in "MILPexec.cxx"
  [9] main(argc = 1, argv = 0xeffff5dc), line 634 in "milpserver.cc"


The problem is that both my client program and my shared object have
to be linked with ICapeMILPSolverComponentSK.o: the client so that it
can hold an object reference to this type of object, and the shared
object so that it can serve up the object itself. Thus the 
__STATIC_CONSTRUCTOR() call generated by the Solaris compiler from
line 131 of ICapeMILPSolverComponentSK.cc, which is:

const _pof_ICapeMILPSolverComponent _the_pof_ICapeMILPSolverComponent;

gets invoked more than once (in fact there would be several such
calls, this is just the first).

Any help appreciated!

Ben Keeping
Imperial College