linking on OSX Snow Leopard
benjamin.kaplan at case.edu
Sun Oct 24 23:12:50 CEST 2010
On Sun, Oct 24, 2010 at 4:15 PM, john skaller
<skaller at users.sourceforge.net> wrote:
> I'm not able to find the shared library version of Python3 on my Mac.
> There are libpython.dylib things for Python2. There is a Python3
> libpython.a static lib.
> The docs on linking indicate a serious problem, there is mention
> of applications containing symbols needed by dynamically loaded
> Unfortunately this idea is seriously broken (on all platforms) and should
> not be used by quality products .. Python is quality product isn't it?
> The correct way to do this is for the extension to be explicitly linked
> against libpython so they find their symbols when loaded.
> The problem with linking against an application is that it may not
> be an application which is loading them .. it could be another shared
> library, and in my case it is.
> in any case I find this:
> ~/felix>ls -lasp /Library/Frameworks/Python.framework/Versions/3.1/bin/python3.1
> 64 -rwxrwxr-x 1 root admin 29560 2 Jun 2009 /Library/Frameworks/Python.framework/Versions/3.1/bin/python3.1
> and clearly a 29K byte executable must be loading a shared library somehow, but only
> one is listed (the dynamic loader itself).
> Do I have to build Python myself to get around this deficiency?
> Does the build script handle this correctly? (The standard Python
> executable must be a thunk that doesn't nothing by run
> a function inside a shared library). Or has something changed
> in the build for Python 3, such as a collection of shared objects
> instead of a monolithic libpython?
You're using a Mac OS X Framework. The structure of the frameworks is
very specific. I believe that
/Library/Frameworks/Python.framework/Versions/3.1/Python will be your
If you want your program to behave appropriately on OS X, you may want
to learn to use the Frameworks rather than just assuming you're on a
standard Unix system.
> BTW: What I'm *actually* doing is: I have a compiler that generates shared libraries which
> are run by an fixed executable driver. I want to be able to run Python from
> inside my programs, but they're not "applications" they're shared libraries (.dylib on OSX).
> In addition, my compiler can produce Python extension modules, which I want to
> use from python scripts. Writing C extensions to Python is hard work for the
> average user. It should be much easier to use my language to define functions
> which can then be used in Python (but run millions of times faster).
> The most interesting option (for me, anyhow), is to do both at the same
> time: embed Python into my programs and use it to load the extension
> modules.. this allows Python to handle some of the dynamics.
> In particular my product's build script is entirely pure Python code
> (so everything builds on all platforms including Windows).
> We want to optionally replace some of the modules with
> compiled extensions, which I can produce, but I also
> want to USE some of the components from the build
> system inside my programs (which, recall, are shared
> john skaller
> skaller at users.sourceforge.net
More information about the Python-list