quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gregory (Grisha) Trubetskoy" <gri...@apache.org>
Subject Re: [PATCH] Allow linking to Python framework
Date Wed, 27 Nov 2002 15:58:59 GMT

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
>


Mime
View raw message