Since I can't see in the prior discussion mention of the error given by the traceback, can you go back to square one and explain your specific problem from the start rather than just assuming it is related to the prior one. Not knowing the background of what you are doing makes it hard to comment.
Graham On 25/04/2013, at 5:28 AM, ultra909 <[email protected]> wrote: > Hi, > > I have EXACTLY the same problem as you. Have done all that and yet still get > nothing out of Apache other than: > > [Wed Apr 24 15:15:55 2013] [info] mod_wsgi (pid=10234): Python home > /home/strongshell/workspace/python/epd-7.3-1/. > [Wed Apr 24 15:15:55 2013] [info] mod_wsgi (pid=10234): Initializing Python. > Traceback (most recent call last): > File "/usr/lib/python2.7/site.py", line 562, in <module> > main() > File "/usr/lib/python2.7/site.py", line 544, in main > known_paths = addusersitepackages(known_paths) > File "/usr/lib/python2.7/site.py", line 271, in addusersitepackages > user_site = getusersitepackages() > File "/usr/lib/python2.7/site.py", line 246, in getusersitepackages > user_base = getuserbase() # this will also set USER_BASE > File "/usr/lib/python2.7/site.py", line 236, in getuserbase > USER_BASE = get_config_var('userbase') > File "/usr/lib/python2.7/sysconfig.py", line 577, in get_config_var > return get_config_vars().get(name) > File "/usr/lib/python2.7/sysconfig.py", line 476, in get_config_vars > _init_posix(_CONFIG_VARS) > File "/usr/lib/python2.7/sysconfig.py", line 337, in _init_posix > makefile = _get_makefile_filename() > File "/usr/lib/python2.7/sysconfig.py", line 331, in _get_makefile_filename > return > os.path.join(get_path('platstdlib').replace("/usr/local","/usr",1), "config" > + (sys.pydebug and "_d" or ""), "Makefile") > AttributeError: 'module' object has no attribute 'pydebug' > > > Clearly it's still hitting the base system python somehow - can't even get it > to run a simple wsgi to dump out sys variables. My WSGIPythonHome is set to > the directory above lib and bin... ldd looks all good... any ideas? > > TIA > > On Thursday, 10 January 2013 20:45:26 UTC+1, Isaac Shivvers wrote: > 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, 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]> 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 unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/modwsgi?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/modwsgi?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
