On Sat, Oct 30, 2010 at 6:40 PM, Martin v. Löwis <report@bugs.python.org>wrote:

It may be there is none. You need to read the bit where I explain that I am
not building Python, I'm grabbing pre-made packages, for OSX and for Ubuntu.

The problem is that these packages don't seem to supply a dynamic link
version.

My problem cannot be solved by telling me I can build Python myself with
the --enable-shared switch, because I am not the client. I am a vendor
supplying a tool that can generate Python shared libraries which cannot run
unless the CLIENT has a shared library version of libpython. So you're
telling me to tell THEM to build Python with --enable-shared switch which is
out of the question for many of them, who may, for example, be programmers
working in a shop where they do not have the ability to change the system
installed by their system admin.

So the problem is that the *packagers* are not supplying the dynamic lib.

Surely that is not the Python dev's issue directly, but it IS an issue the
Python dev's can do something about, by talking to the packagers.

Anyhow, I will give up. I can't test the feature of the compiler I have
implemented
because I don't have a libpython.so and I have no intention of building one,
because I can't expect all those Python users out there to do it either.

It seems you really don't understand the requirements for dynamic linking:
my application code is exclusively in a dlopen()d shared library, so if it
is
used AS a python module or it wants itself to USE a Python extension
module OR Python interpreter itself, it cannot do so.

The top level application is a fixed mainline which does not include
libpython.a or any such symbols.

It's a basic design principle, Meyer called it "the principle of explicit
interfaces"
which means: if you depend on something make the dependency explicit.

Extension modules which do not *explicitly* link against libpython break
this rule.