[PATCH] Allow linking to Python framework

[Justin Erenkrantz <je...@apache.org>]

Okay, here's the caveat I mentioned in my previous post.  This really
isn't a mod_python issue, but an embedded python one.

Python doesn't allow embedding of the interpreter on Darwin due to
its use of bundles.  mod_python fails when 'import time' is called,
because by default time is built as a dynload shared object. However,
on Darwin, those are MH_BUNDLEs which are tied to a particular
executable - in this case, python.  Therefore, 'time' can't be
imported via mod_python since its executable is 'httpd.' But,
mod_python's apache module imports it.  So, I'm totally confused how
this ever worked.  *sigh*  (I have a hunch that I just deleted the
'import time' line before.)

The good news is that in Python HEAD (2.3a0), there's a new
dynload_next.c which is a substantial rewrite of the Darwin DSO code.
It emits the system error when a DSO load fails (2.2 emits a generic
non-helpful error message)!  As soon as I saw the error referring to
the bundles, the solution was obvious (you have no idea how long it
took me to get to this point).  I actually unknowingly duplicated
their code and was going to submit a patch when I saw that there was
already a rewrite on HEAD of python (hence, I just bumped up to
2.3a0).

And, the framework support is much improved in HEAD cf. 2.2.  So, I'd
recommend that Darwin mod_python users bite the bullet and use Python
HEAD with a framework installation.  I really can't figure out how to
do it otherwise when the dynload modules are really MH_BUNDLEs
statically tied to 'python' binary.  There's no way what 2.2 is doing
can work for embedded interpreters on Darwin.

So, this simple patch allows for python built as a Darwin framework
to be recognized by mod_python.  This works for me with framework and
non-framework compiles.  Python places 'no-framework' as the value
when the framework isn't built regardless of platform.  -- justin

Re: [PATCH] Allow linking to Python framework

["Gregory (Grisha) Trubetskoy" <gr...@apache.org>]

Funny - I too spent like hours reading Apple docs, and hacked
dynload_next.c to show the text of the error :)

I don't know if you noticed it in the mod_python README "OS Hints"
section, but you can also define DYLD_FORCE_FLAT_NAMESPACE environ var and
"import time" will suddenly work.

I suspect some fink packages use this trick, so it's possible that it
worked at one time for you because the variable was set for some reason.

On Wed, 27 Nov 2002, Justin Erenkrantz wrote:

> Okay, here's the caveat I mentioned in my previous post.  This really
> isn't a mod_python issue, but an embedded python one.
>
> Python doesn't allow embedding of the interpreter on Darwin due to
> its use of bundles.  mod_python fails when 'import time' is called,
> because by default time is built as a dynload shared object. However,
> on Darwin, those are MH_BUNDLEs which are tied to a particular
> executable - in this case, python.  Therefore, 'time' can't be
> imported via mod_python since its executable is 'httpd.' But,
> mod_python's apache module imports it.  So, I'm totally confused how
> this ever worked.  *sigh*  (I have a hunch that I just deleted the
> 'import time' line before.)
>
> The good news is that in Python HEAD (2.3a0), there's a new
> dynload_next.c which is a substantial rewrite of the Darwin DSO code.
> It emits the system error when a DSO load fails (2.2 emits a generic
> non-helpful error message)!  As soon as I saw the error referring to
> the bundles, the solution was obvious (you have no idea how long it
> took me to get to this point).  I actually unknowingly duplicated
> their code and was going to submit a patch when I saw that there was
> already a rewrite on HEAD of python (hence, I just bumped up to
> 2.3a0).
>
> And, the framework support is much improved in HEAD cf. 2.2.  So, I'd
> recommend that Darwin mod_python users bite the bullet and use Python
> HEAD with a framework installation.  I really can't figure out how to
> do it otherwise when the dynload modules are really MH_BUNDLEs
> statically tied to 'python' binary.  There's no way what 2.2 is doing
> can work for embedded interpreters on Darwin.
>
> So, this simple patch allows for python built as a Darwin framework
> to be recognized by mod_python.  This works for me with framework and
> non-framework compiles.  Python places 'no-framework' as the value
> when the framework isn't built regardless of platform.  -- justin
>