[omniORB] omniORBpy and Mac OSX 10.3: workaround, fink packages

[Piet van Oostrum]

>>>>> Asa MacWillliams <macwilli at in.tum.de> (AM) wrote on Thu, 15 Jan 2004:

AM> Hi again,
AM> as I reported previously, under Mac OS 10.3, omniORBpy fails to initialize
AM> properly, due to what I think is a Mac OS dynamic library loader bug.

AM> A workaround is to compile omniORBpy to link _omnipymodule.so against the
AM> omniORB libraries statically, rather than dynamically.

AM> One way to achieve this is to temporarily remove libombni*.dylib while
AM> omniORBpy is linking, so libomni*.a are used instead. I'll try to find
AM> better build method soon.

I have done this and it works. However, now I want to use the omnisslTP
module (from omniORB.sslTP import *), and it generates a lot of undefined
symbols, like:
ImportError: Failure linking new module: : dyld: python Undefined symbols:
__ZN17_omniFinalCleanupC1Ev
__ZN17_omniFinalCleanupD1Ev
__ZN20_CORBA_String_helper12empty_stringE
__ZN4omni10assertFailEPKciS1_
__ZN4omni11LibcWrapper11getaddrinfoEPKct
__ZN4omni11LibcWrapper12freeaddrinfoEPNS0_8AddrInfoE
__ZN4omni12omniExHelper10INITIALIZEEPKcimN5CORBA16CompletionStatusE
__ZN4omni13tcpConnection11ip4ToStringEmtPKc
__ZN4omni15omniInitialiser7installEPS0_
__ZN4omni16SocketCollection10findSocketEib
__ZN4omni16SocketCollection12dec

I can understand this, as the omnisslTP doesn't know these symbols were
loaded in omnipymodule. Unfortunately I can't tell omnisslTP to link
against omnipymodule. Does anybody know a way around this?
(I thought making a symbolic link to libomnipymodule.dylib would work but
it doesn't).
-- 
Piet van Oostrum <piet at cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP]
Private email: P.van.Oostrum at hccnet.nl