pkgsrc-Users archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
[patch] Re: www/ap2-wsgi (apache mod_wsgi): unable to find pkgsrc python2.7 on system with native python2.7
> > > It is strange that mod_wsgi searches for a "python" executable, even
> > > though it was provided with a full path to it at compile time
> > > (CONFIGURE_ARGS+= --with-python=${PYTHONBIN:Q} ). And then there is also
> > > the explicit "python-path" setting in the configuration, obviating the
> > > need for autodetection.
Seems this is documented behaviour of python:
https://docs.python.org/2/c-api/init.html#c.Py_SetProgramName
And from
https://groups.google.com/forum/?_escaped_fragment_=topic/modwsgi/Rmgj8IcHC18#!topic/modwsgi/Rmgj8IcHC18
I understand it is on purpose that in recent versions mod_wsgi does not
use this function anymore, as it does not work on OS X or Windows.
(explains why --with-python=<path/to/python> has no effect)
But setting WSGIPythonHome or the WSGIDaemonProcess python-home
arguments to "/opt/pkgsrc" as explained by
https://docs.python.org/2/using/cmdline.html#envvar-PYTHONHOME
did not help either.
Attached patch adds back calling Py_SetProgramName() before
Py_Initialize().
mod_wsgi now finds its own libraries again, even against a
/usr/bin/python from the system base install.
Can someone using OS X test this patch?
Regards
Matthias
$NetBSD$
--- Makefile.in.orig 2014-06-18 11:18:49.000000000 +0000
+++ Makefile.in
@@ -19,7 +19,7 @@ DESTDIR =
LIBEXECDIR = @LIBEXECDIR@
CPPFLAGS = @CPPFLAGS@
-CFLAGS = @CFLAGS@
+CFLAGS = @CFLAGS@ -DPYTHON_EXE='@PYTHON@'
LDFLAGS = @LDFLAGS@
LDLIBS = @LDLIBS@
$NetBSD$
--- src/server/wsgi_interp.c.orig 2014-06-18 11:18:49.000000000 +0000
+++ src/server/wsgi_interp.c
@@ -2046,6 +2046,49 @@ void wsgi_python_init(apr_pool_t *p)
_wputenv(L"PYTHONIOENCODING=cp1252:backslashreplace");
#endif
+ /* If ProgramName is not set, Py_Initialize will search $PATH
+ * for a "python" executable (usually a symlink to the versioned
+ * binary name) that fits its own version and derives the
+ * library search paths to use from this location.
+ *
+ *
+ * Note: this executable is not actually executed, it is only
+ * the location of the binary that is used.
+ *
+ * https://docs.python.org/2/c-api/init.html#c.Py_SetProgramName
+ * ------------------------------------------------------------
+ * void Py_SetProgramName(char *name)
+ * This function should be called before Py_Initialize() is
+ * called for the first time, if it is called at all. It
+ * tells the interpreter the value of the argv[0] argument
+ * to the main() function of the program. This is used by
+ * Py_GetPath() and some other functions below to find the
+ * Python run-time libraries relative to the interpreter
+ * executable. The default value is 'python'. The argument
+ * should point to a zero-terminated character string in
+ * static storage whose contents will not change for the
+ * duration of the program's execution. No code in the
+ * Python interpreter will change the contents of this
+ * storage.
+ * ------------------------------------------------------------
+ *
+ * pkgsrc python packages do not provide a "python" symlink,
+ * just the versioned binary name, e.g. "python2.7".
+ * The embedded python interpreter in WSGI might find a
+ * "python" executable at other places in $PATH, even of the
+ * correct version but with different libraries (i.e. some might
+ * be missing). WSGI then will fail to properly initialize,
+ * rendering all of apache unusable.
+ *
+ * https://groups.google.com/forum/?_escaped_fragment_=topic/modwsgi/Rmgj8IcHC18#!topic/modwsgi/Rmgj8IcHC18
+ * states that Py_SetProgramName does not work on OSX or Windows
+ */
+#define stringify_literal( x ) # x
+#if defined(PYTHON_EXE) && !defined(WIN32)
+ Py_SetProgramName(stringify_literal(PYTHON_EXE));
+#endif
+
+
/* Initialise Python. */
ap_log_error(APLOG_MARK, APLOG_INFO, 0, wsgi_server,
Home |
Main Index |
Thread Index |
Old Index