linking on OSX Snow Leopard

[Benjamin Kaplan]

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.
>
> <aside>
> The docs on linking indicate a serious problem, there is mention
> of applications containing symbols needed by dynamically loaded
> extensions.
>
> 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.
> </aside>
>
> 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
shared library.

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.
http://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPFrameworks/Frameworks.html

> 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
> libraries).
>
> --
> john skaller
> skaller at users.sourceforge.net
>
>
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>