[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 --