Thanks for all the help!  I finally got it working, but weirdly, it
came down to how python's shared library loader works on OS X.

A default python build on OS X uses Python/dynload_next.c (as in
NeXT), which knows how to load shared libraries that are "bundles". 
This loader is what fails to load _xpcom.so / lib_xpcom.dylib and
throws the ImportError, "Inappropriate file type for dynamic loading".
 From what I gather from some apple docs, the functions used in
dynload_next.c can only load bundles, and but not load normal shared
libraries.  I can't believe this is right, since my dynload_next built
python uses all sorts of swig-wrapped shared libraries that don't look
like bundles, but whatever, it doesn't work for pyxpcom's shared
libraries.

Apple's build of python uses the library loader
Python/dynload_shlib.c, the standard unix-y one.  (Thank god for the
saved lib/python2.3/config/Makefile !)  If I build my own python using
that one via DYNLOADFILE=dynload_shlib.o, I can load _xpcom.so just
fine, and run the pyxpcomxul test extension!

I can't find too much mention of this problem on the internet ... some
person blogged about doing this fix to get python to link to
openoffice shared libraries...

No one else has ever run into this thing?  I feel like I just spent a
ton of time with the most obscure problems ever..

Brendan


On 8/18/05, Trent Mick <trentm@[...].com>  wrote:
>  > We didn't do any work towards locating python in a non-standard
>  > location.  I'll have to look into what we did to make this use the
>  > python in our Komodo.app/Frameworks/Python.framework.  I think we do
>  > something post build to force the linkage to the executable's python
>  > framework.  Our linkage for _xpcom.so looks like:
>  >
>  > otool -L /Applications/Komodo.app/Contents/MacOS/python/xpcom/_xpcom.so
>  > /Applications/Komodo.app/Contents/MacOS/python/xpcom/_xpcom.so:
>  >         @executable_path/libxpcom.dylib (compatibility version 1.0.0,
>  > current version 1.0.0)
>  >         @executable_path/libplds4.dylib (compatibility version 1.0.0,
>  > current version 1.0.0)
>  >         @executable_path/libplc4.dylib (compatibility version 1.0.0,
>  > current version 1.0.0)
>  >         @executable_path/libnspr4.dylib (compatibility version 1.0.0,
>  > current version 1.0.0)
>  >         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
>  > current version 71.1.3)
>  >
>  > @executable_path/../Frameworks/Python.framework/Versions/2.4/Python
>  > (compatibility version 2.4.0, current version 2.4.0)
>  
>  Yes, we use 'install_name_tool' to change the Python linkage. Something
>  like:
>  
>      install_name_tool -change OLD/PATH >         @executable_path/../Frameworks/Python.fra
mework/Versions/2.4/Python >          path/to/libpyloader.dylib
>  
>      install_name_tool -change OLD/PATH >         @executable_path/../Frameworks/Python.fra
mework/Versions/2.4/Python >          path/to/xpcom/_xpcom.so
>  
>  Trent
>  
>  --
>  Trent Mick
>  TrentM@[...].com
> 

_______________________________________________
pyxpcom mailing list
pyxpcom@[...].com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs