[Pythonmac-SIG] Python C extensions that depend on dynamic libraries

Bob Tolbert bob at eyesopen.com
Sun Jan 11 12:24:02 EST 2004


Hi,

I've been a bit of a lurker on this list for a while so I want to start 
by saying a big thank you to the all involved for making the Mac such a 
Python-friendly place. I'm posting here hoping that some of the more 
experienced Mac developers can maybe send me in the right direction, as 
I am currently at a loss.

For a bit of background, my company ships a Python wrapper for a C++ 
toolkit. We've had versions for OS X as well as Windows and most major 
Unices for about a year now. Up til now, we've built the Python 
extension (bundle in Mac parlance) against a static library containing 
the C++ code. We are migrating to a shared library approach for the 
underlying C++ libraries to allow additional toolkits (that extend the 
base toolkit) to also be wrapped in Python. By the summer, we hope to 
ship all our toolkits with Python API's.  All of the extension code is 
generated by SWIG (1.3.20) but I don't think that has much to do with 
my current problem.

So, in switching to shared libraries, I've encountered loads of fun and 
platform-specific behavior on Linux and Win32 as well as OS X. I've got 
Linux and Win32 working and am now frustrated that my primary 
development platform still won't work.

So here's the scenario. The following two work.

1.  Build C++ libraries as static libraries then build Python extension 
as -bundle
2.  Build C++ libraries as dynamic libraries and then build C++ apps 
that depend on them. The apps will run, loading the dynamic library at 
runtime.

But what still fails to work is the combination:

3. Build C++ library as dynamic library then build Python extension 
dependent on it.  So I have a python shadow/proxy class file foo.py 
that loads the actual python extension _foo.so that depends on the C++ 
library foo.dylib. I have have set DYLD_LIBRARY_PATH, etc. The behavior 
I see is that if I import foo, it imports _foo.so and then Python 
hangs, forever. I have to kill it from the commandline.

So now that I've bored you with more details than I should have, I am 
really asking for some ideas of where to look for the straight scoop on 
the is whole dylib/so dichotomy in OS X.  I am pretty sure I had an 
early prototype of this working under 10.2, but it seems Apple has 
changed some of the commandline switches for building dylibs in 10.3. 
First there is this whole issue of two-level namespaces and then there 
are all the command line switches concerning undefined symbols

thanks for listening and for any clues,

Bob Tolbert
OpenEye Scientific Software, Inc.
bob at eyesopen.com




More information about the Pythonmac-SIG mailing list