Hi all, Just a quick bump, bringing this post back to life.
I'm running a similar setup, and had a very similar problem: - attempting to run a mod_wsgi application using a specific, custom Enthought python build - used multiple-python guide here<http://code.google.com/p/modwsgi/wiki/InstallationIssues>, and it appeared successful - but, I still had problems: - libraries that should work (numpy) did not - sys.version (inside wsgi application) reported default system version, not the one I wanted But, modifying the LD_RUN_PATH with make worked like a charm! I re-compiled mod_wsgi, as Graham suggested: make distclean ./configure --with-python=/path/to/python/executable LD_RUN_PATH=/path/to/python/lib make sudo make install Thanks for all the work you've put into mod_wsgi! -Isaac On Tuesday, May 3, 2011 4:46:30 PM UTC-7, Graham Dumpleton wrote: > > On 4 May 2011 03:41, Daniel O'Donovan <[email protected] <javascript:>> > wrote: > > Thanks for your help Graham, embarrassingly, many of my problems stemmed > from using > > > > $ service httpd restart > > > > to control my apache daemon rather than > > > > $ /etc/init.d/httpd restart > > > > As 'service' will remove some of your environment variables (PYTHONHOME > seems to be key - WSGIPythonHome didn't seem to have any effect). > > You should never rely on environment variables set in user environment > being inherited because when box reboots it will fail. > > As I said before, WSGIPythonHome doesn't help with which shared > library is found, only the runtime Python installation prefix. Your > comments before suggested sys.path was correct which indicated that > WSGIPythonHome was at least doing it job correctly. As per the > documented I directed you to, the important value is sys.prefix and > what that is set to within mod_wsgi. > > WSGIPythonHome should work so long as mod_python not loaded, you get > the prefix you give it correct, Apache can read the directories for > the installation and you haven't managed to inherit user environment > variables that screw it all up. > > >> What do you mean here? Ie., what does patchelf do and how does it > >> change the output from ldd on mod_wsgi.so? > > > > patchelf modifies the dynamic linker and RPATH of ELF executables. > Unfortunately setting --with-python= and LD_RUN_PATH had no effect for me, > so but a quick > > > > $ patchelf --set-rpath /lib64:/path/to/my/custom/lib > /etc/httpd/modules/mod_wsgi.so > > > > did the job. - ldd now searches for dynamic libs in /lib64 and > /path/to/my/custom/lib and finds the appropriate non-system python. > > Setting LD_RUN_PATH in user environment when building mod_wsgi should > work. I can't say what you have done wrong as you haven't supplied > exact logs of what commands you ended up running to build it and what > subsequent ldd output was. Also don't know what other user environment > variables you had set which could cause problems. > > Anyway, if you have got it working then doesn't matter I guess. > > Graham > > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To view this discussion on the web visit https://groups.google.com/d/msg/modwsgi/-/zQzULX4KIBIJ. 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.
