linking on OSX Snow Leopard

[john skaller]

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?


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