On 3 May 2011 00:58, Dan O'Donovan <[email protected]> wrote: > Dear mod_wsgi community, > > I'm trying to build mod_wsgi by linking to different custom build and > install python versions on a 64 bit linux FC 14 (without mod_python) > and using both mod_wsgi 3.3 and the latest mercurial checkout. > > The builds compile and run successfully, but I am noticing some > strange behaviour - please let me know if this is expected! Without > any LD_LIBRARY_PATH or RPATH etc. environment variables set, and > configuring with > > $ ./configure --with-python=/path/to/custom/bin/python && make && make > install > > produces a mod_wsgi.so which ldd tells me is linked to system python, > not /path/to/custom: > > $ ldd /etc/httpd/modules/mod_wsgi.so > linux-vdso.so.1 => (0x00007ffffebae000) > libpython2.7.so.1.0 => /usr/lib64/libpython2.7.so.1.0 > (0x00007f9c5ac13000) > <snip>
Yes, that will happen because the directory where the custom Python shared library is installed is not going to be in the default shared library search path. > When this module is loaded into apache, and I set WSGIPythonHome to / > path/to/custom wsgi/python tells me that I have the correct PYTHONPATH > libraries loaded (sys.path), Which is all WSGIPythonHome is for. That is, to determine the runtime location of the Python installation when not in a standard location. It doesn't affect which Python shared library is used as that is too late, with the operating system runtime program linker having done that long before. > but sys.executable is pointing to /usr/ > bin/python (system python) and not /path/to/custom/bin/python Because it is an embedded system and doesn't actually execute the command line Python that will be the case. The value of sys.executable in other words is crap and should be ignored. > I find this quite confusing as I explicitly set --with-python= when > configuring. I can load both /usr/bin/python and /path/to/custom > python as they are both 2.7 - but I have a need for a python version > which isn't identical to system python - in this instance the > mod_wsgi.so refuses to load with > > [Sun May 01 03:27:01 2011] [warn] mod_wsgi: Compiled for Python/2.7.1. > [Sun May 01 03:27:01 2011] [warn] mod_wsgi: Runtime using Python/2.7. > [Sun May 01 03:27:01 2011] [info] mod_wsgi (pid=24460): Python home / > opt/dev/base-py2.7. > [Sun May 01 03:27:01 2011] [info] mod_wsgi (pid=24460): Initializing > Python. > ImportError: No module named site > > (which is expected as Compiled python 2.7.1 is not the same as Runtime > Python 2.7) The version mismatch here is purely because the shared library used was the wrong one. > I have used patchelf to change the libraries that the shared library > is linking to, but wsgi is still invoking system python not custom > python. What do you mean here? Ie., what does patchelf do and how does it change the output from ldd on mod_wsgi.so? > I've read up on > http://code.google.com/p/modwsgi/wiki/InstallationIssues%23Multiple_Python_Versions > which was very helpful, but I can't seem to navigate around this > issue. > > Can anyone spot anything obviously wrong with what I'm doing? Is there > a way to change Runtime python to avoid all this? You don't have a choice but to set LD_RUN_PATH at compile time in environment when building mod_wsgi from source code in your case. As well as the page you reference, also see: http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation So, in mod_wsgi source code do: make distclean ./configure --with-python=/opt/dev/base-py2.7/bin/python LD_RUN_PATH=/opt/dev/base-py2.7/lib make sudo make install After having done that, see if 'ldd' then correctly shows the right executable. Graham -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
