[omniORB] More on omniORB4 on Mac OSX
William Noon
noon@snow.nrcc.cornell.edu
Mon, 11 Feb 2002 12:46:05 -0500
On Mon, 11 Feb, Duncan Grisby wrote:
> On Friday 1 February, William Noon wrote:
>
> > Following Duncan's suggestion of an overzealous link optimizer, I added
> > an OMNI_EXPORT_LINK_FORCE_SYMBOL(poa); to poa.cc and OMNI_FORCE_LINK(poa);
> > to (for want of a better place) corbaOrb.cc.
>
> I don't suppose these issues go away with the flat-namespace option do
> they?
>
> Getting things to work with Python may require compiling Python's
> main() with C++, which would be a shame.
>
Duncan -- I tracked down a few ways to get Apple's dynamic linker
to stop being so lazy and bind all undefined symbols when launching.
The first is to set the CXXLINKOPTIONS to include -bind_at_load which
sets a flag in the mach-o executable:
CXXLINKOPTIONS = $(CXXDEBUGFLAGS) $(CXXOPTIONS) -Wl,-bind_at_load -flat_namespace -undefined suppress
This works for the c++ programs. The python programs are a little different.
The quick and dirty solution is to set the DYLD_BIND_AT_LAUNCH environ
variable before running the python program.
Building python with the -bind_at_load option doesn't force the dynamic
library loading code to bind all undefined symbols. I am working with
Steven Majewski's Darwin dynamic loader and trying different load options.
I will follow this up on the osx-dev lists, but for now the
DYLD_BIND_AT_LAUNCH will work.
> > Here is a patch to the net interface discovery code to handle variable length
> > ifreq structures. It is pretty much right out of Stevens:
>
> Did you require that patch for the code to work? The sockaddr struct
> on Linux (and probably others) doesn't have an sa_len member, so the
> patched code fails to compile. I haven't looked into it any further at
> the moment.
This is required to get the discovery code to find any interfaces. There
may have to be some config option to define this. Darwin defines
_SIZEOF_ADDR_IFREQ in net/if.h, so maybe we can use it.
--Bill Noon
>
> Cheers,
>
> Duncan.
>
> --
> -- Duncan Grisby \ Research Engineer --
> -- AT&T Laboratories Cambridge --
> -- http://www.uk.research.att.com/~dpg1 --