[omniORB] omniORBpy 2.3, Mac OSX 10.3 and static initializers

[Zachery Corbiere]

I got omniORB 4.0.4/omniORBpy 2.4 working with the 10.3-included python  
by statically linking the omniorb C++ libraries into omniORBpy.  I did  
it in a pretty cheesy way - compile omniORB and 'make install'.  Then,  
move the omniORB dylib files out of the way before compiling omniORBpy.  
  Then I put the dylib files back.

It has worked in my very limited testing - no double free and I was  
able to resolve initial references to grab the NameService.  I'll try  
to run though the example programs today and see if they work - I  
expect that they will.

On Nov 29, 2004, at 7:10 AM, Eric Noyau wrote:On Nov 29, 2004, at 7:10  
AM, Eric Noyau wrote:

> I'm using the latest omniORB and omniORBpy under Mac OS X 10.3.x. It  
> works fine but you have to do some tuning to get it to work.
>
> First of all you have to recompile your own version of python. The  
> version shipping with the OS was not compiled with C++ support, and as  
> such cannot work with omniORBpy. To do so just download the latest  
> python and configure it with the following arguments:
>
> configure --enable-framework --enable-shared --with-cxx=g++
> make
> sudo make frameworkinstall
>
> This will install a properly configured /usr/local/bin/python. The  
> framework install is not mandatory, but I like it that way, YMMV. The  
> important part is the '--with-cxx=g++'. Once this is installed  
> recompile omniORBpy with this version of python in your path.
>
> The second issue is the static initializer bug: There is some weird  
> interaction between between lazy loading and C++ bundles when the main  
> of the application is not in C++. The net effect is that the static  
> initializers are not run when they should. It's a bug in the linker  
> and Apple is aware of it. Hopefully it will get fixed in 10.4 (cross  
> my fingers...).
>
> To work around the issue you have to disable lazy loading, aka force  
> the linker to resolve all the symbols at launch time. In that case the  
> static initializers are run properly. To do so you have to
>
> export DYLD_BIND_AT_LAUNCH=1
>
> before launching python. Be aware that this has a cost in launch time  
> performance, you don't want to turn this on for the whole system.
>
> With those two things out of the way everything works fine. Almost.  
> There is still an issue I haven't looked at, which is that for some  
> reason omniORB fail to work properly with named sockets. I'm sure it's  
> something simple, but I took the lazy route and used TCP instead.
>
> Regards,
> -- Eric
>
> On 29 Nov 2004, at 6:27, Alan Sill wrote:
>
>> Hi,
>>
>> Regarding the problem with the thread subject listed above in  
>> December 2003, has anyone solved the double free with omniORB and  
>> omniORBpy on Mac OS X?
>>
>> Running into this using older versions, but wanted to see if it has  
>> been fixed in newer ones.
>>
>> Reference: most recent post to date:
>> http://www.omniorb-support.com/pipermail/omniorb-list/2003-December/ 
>> 024780.html
>>
>> Alan Sill, TTU
>>
> _______________________________________________
> omniORB-list mailing list
> omniORB-list at omniorb-support.com
> http://www.omniorb-support.com/mailman/listinfo/omniorb-list