So the Makefile is meant to use -lpython3.4m. There was a time when the ‘m’ was being left off, but that should have been fixed a long time ago.
I will need to dig into what RHEL is doing and why the configuration that Python generates for me doesn’t have the ‘m’. So using -lpython3 or -lpython3.4m will work. Anyway, with it building okay, where are we up to now. Still have encoding issue? Graham > On 20 Oct 2016, at 1:05 PM, Shanti Suresh <[email protected]> wrote: > > Hi Graham, > > I see. I appreciate that feedback. > > I did: > sudo yum install python34 python34-devel > > $ sudo yum install python34 python34-devel > Loaded plugins: langpacks, product-id, rhnplugin, search-disabled-repos, > subscription-manager > This system is receiving updates from RHN Classic or Red Hat Satellite. > Package python34-3.4.3-7.el7.x86_64 already installed and latest version > Package python34-devel-3.4.3-7.el7.x86_64 already installed and latest version > Nothing to do > > I don't mind downgrading to Python 2.7. > > Also, > $ ls -las /usr/lib64/libpython* > 0 lrwxrwxrwx. 1 root root 19 Feb 20 2016 /usr/lib64/libpython2.7.so > -> libpython2.7.so.1.0 > 1780 -rwxr-xr-x. 1 root root 1822520 Oct 11 2015 > /usr/lib64/libpython2.7.so.1.0 > 0 lrwxrwxrwx. 1 root root 20 Oct 19 12:45 /usr/lib64/libpython3.4m.so > -> libpython3.4m.so.1.0 > 2556 -rwxr-xr-x. 1 root root 2615808 Aug 9 13:13 > /usr/lib64/libpython3.4m.so.1.0 > 8 -rwxr-xr-x. 1 root root 6688 Aug 9 13:13 /usr/lib64/libpython3.so > > Thanks, > > -Shanti > > On Wednesday, October 19, 2016 at 9:46:42 PM UTC-4, Graham Dumpleton wrote: > What do you get for: > > ls -las /usr/lib64/libpython* > > There should be a libpython3.4. If there isn’t there is something a bit wonky. > > Is the Python 3.4 definitely a system package? I actually didn’t think RHEL > 7.2 had Python 3. > > As far as doing software development on RHEL, one generally should avoid > using the system Python and instead use Python installed from Software > Collections Library. These are not installed under /usr, but down under /opt > somewhere. > > Graham > >> On 20 Oct 2016, at 12:39 PM, Shanti Suresh <shantis...@ <>gmail.com >> <http://gmail.com/>> wrote: >> >> Hi Graham, >> >> As much distracting as the debate is, the build of mod_wsgi actually isn't >> without event. I have to go in and modify the Makefile. >> I change -lpython3.4 to -lpython3 >> >> And then the make succeeds. Otherwise, "make" fails as follows: >> >> $ make | tee make5.log >> ... >> /usr/lib64/apr-1/build/libtool --silent --mode=link gcc -std=gnu99 >> -Wl,-z,relro,-z,now -o mod_wsgi.la <http://mod_wsgi.la/> -rpath >> /usr/lib64/httpd/modules -module -avoid-version mod_wsgi.lo -L/usr/lib64 >> -L/usr/lib64/python3.4/config -lpython3.4 -lpthread -ldl -lutil -lm >> /usr/bin/ld: cannot find -lpython3.4 >> collect2: error: ld returned 1 exit status >> apxs:Error: Command failed with rc=65536 >> >> Could that be the problem? >> >> Thanks, >> >> -Shanrti >> On Wednesday, October 19, 2016 at 9:11:59 PM UTC-4, Graham Dumpleton wrote: >> The only other can think of is that the main Python installation was >> patched/upgraded between when virtual environment was created and when it >> was used. This can cause some strange problems to occur and necessitates >> recreation of the virtual environment. >> >> Graham >> >>> On 20 Oct 2016, at 12:06 PM, Graham Dumpleton <graham.d...@ <>gmail.com >>> <http://gmail.com/>> wrote: >>> >>> If your Python 3 is the system Python, then LD_RUN_PATH shouldn’t be needed. >>> >>> I presume you mean pyvenv and not pyenv as pyenv is a tool for installing >>> whole Python installations, not just virtual environment. >>> >>> The preference is to use virtualenv over pyvenv as know virtualenv always >>> works. >>> >>> Graham >>> >>>> On 20 Oct 2016, at 12:03 PM, Shanti Suresh <shantis...@ <>gmail.com >>>> <http://gmail.com/>> wrote: >>>> >>>> Hi Graham, >>>> >>>> Thank you. >>>> >>>> I tried with both pyenv as well as virtualenv and both times, it is the >>>> "encodings" module. >>>> >>>> Thank God, it is not 'django' anymore. I will try recompiling. The >>>> Python binaries include: >>>> /usr/bin/python2.7 >>>> /usr/bin/python2.7-config >>>> /usr/bin/python3.4 >>>> /usr/bin/python3.4m >>>> /usr/bin/python3.4m-x86_64-config >>>> >>>> -Shanti >>>> >>>> On Wednesday, October 19, 2016 at 8:51:41 PM UTC-4, Graham Dumpleton wrote: >>>> Do you have multiple Python 3 versions installed on your system? >>>> >>>> It may be picking up wrong shared library at run time: >>>> >>>> >>>> http://modwsgi.readthedocs.io/en/develop/user-guides/checking-your-installation.html#python-shared-library >>>> >>>> <http://modwsgi.readthedocs.io/en/develop/user-guides/checking-your-installation.html#python-shared-library> >>>> >>>> The solution to that if it is the case, is to work out where the shared >>>> library is for the main Python installation of version you want to use is, >>>> and set the LD_RUN_PATH environment at the time of compilation to where >>>> that directory is. For example, if Python 3 you want to use is under >>>> /usr/local, use: >>>> >>>> make distclean >>>> ./configure --with-apxs=/usr/bin/apxs >>>> --with-python=/usr/local/bin/python3 >>>> LD_RUN_PATH=/usr/local/lib make >>>> sudo make install >>>> >>>> BTW, are you using Anaconda Python? >>>> >>>> Did you use virtualenv or pyvenv to create the Python virtual environment. >>>> >>>> The pyvenv approach is broken for when embedding Python. I had a >>>> workaround for it, but is possible some recent changes I made so that >>>> Anaconda Python would work has upset that. Or the workaround will not work >>>> for Anaconda Python anyway. >>>> >>>> Graham >>>> >>>>> On 20 Oct 2016, at 11:44 AM, Shanti Suresh <shantis...@ <>gmail.com >>>>> <http://gmail.com/>> wrote: >>>>> >>>>> Hi Graham, >>>>> >>>>> Thanks so much for your response. >>>>> >>>>> With those changes, I get: >>>>> >>>>> Fatal Python error: Py_Initialize: Unable to get the locale encoding >>>>> ImportError: No module named 'encodings' >>>>> >>>>> I also removed "lang='en_US.UTF-8' locale='en_US.UTF-8’" just for fun, >>>>> but I still get the error about encodings. >>>>> I don't have an "encodings" module in my Django project. >>>>> >>>>> Thanks again, >>>>> >>>>> -Shanti >>>>> >>>>> On Wednesday, October 19, 2016 at 8:15:32 PM UTC-4, Graham Dumpleton >>>>> wrote: >>>>> >>>>>> On 20 Oct 2016, at 10:56 AM, Shanti Suresh <[email protected] <>> >>>>>> wrote: >>>>>> >>>>>> Greetings, >>>>>> >>>>>> Thank you for your help, in advance! It has been a frustrating day. >>>>>> >>>>>> I have a virtualenv configured with Python3.4.3 on RedHat release 7.2. >>>>>> >>>>>> I configured mod_wsgi-3.4 as: >>>>>> ./configure --with-apxs=/usr/bin/apxs >>>>>> --with-python=/usr/local/dev/env/bin/python3 >>>>> >>>>> Are you using your own Python installation or that from the Software >>>>> Collections Library? I am presuming it is your own rather than SCL as SCL >>>>> latest is Python 3.4.2. Just want to make sure. >>>>> >>>>> Anyway, even if you intend to use a virtual environment, it is often >>>>> better to still compile mod_wsgi against the main Python installation. >>>>> This will avoid complications if later want to have multiple daemon >>>>> process groups using different Python virtual environments. >>>>> >>>>> So would recommend doing a: >>>>> >>>>> make distclean >>>>> >>>>> then rerun configure but this time use the python3 from where it was >>>>> originally installed. >>>>> >>>>>> make >>>>>> sudo cp .libs/mod_wsgi.so /etc/httpd/modules/ >>>>>> >>>>>> -- >>>>>> My wsgi.py file reads: >>>>>> import os >>>>>> os.environ.setdefault("DJANGO_SETTINGS_MODULE", >>>>>> "knack_djangoapp.settings_temp") >>>>>> >>>>>> from django.core.wsgi import get_wsgi_application >>>>>> application = get_wsgi_application() >>>>>> -- >>>>>> -- >>>>>> In httpd.conf, I have: >>>>> >>>>> Because best practice is to always use daemon mode, I would recommend >>>>> adding outside of VirtualHost, usually just after where the wsgi_module >>>>> is loaded: >>>>> >>>>> WSGIRestrictEmbedded On >>>>> >>>>> This will prevent Python being initialised in the Apache child worker >>>>> processes and will only be initialised in daemon processes. >>>>> >>>>> If your configuration isn’t quite right and for some reason it tries to >>>>> run stuff in embedded mode, you will now get an error saying something is >>>>> wrong. Thus helps to avoid mistakes. >>>>> >>>>>> <VirtualHost *:81> >>>>>> DocumentRoot /var/www/html/dev >>>>>> ServerName dev.domain.edu <http://dev.domain.edu/> >>>>>> WSGIDaemonProcess dev >>>>>> python-path=/usr/local//dev/djangoapp:/usr/local/dev/env/lib/python3.4/site-packages/ >>>>>> lang='en_US.UTF-8' locale='en_US.UTF-8’ >>>>> >>>>> Recommend using: >>>>> >>>>> WSGIDaemonProcess dev python-home=/usr/local/dev/env >>>>> python-path=/usr/local//dev/djangoapp lang='en_US.UTF-8' >>>>> locale='en_US.UTF-8’ >>>>> WSGIApplicationGroup %{GLOBAL} >>>>> >>>>> The important bit here is using python-home to set the location of the >>>>> virtual environment. This will be what sys.prefix is set to for Python >>>>> when run under the virtual environment. Don’t set up the virtual >>>>> environment using site-packages in python-path. >>>>> >>>>> The WSGIApplicationGroup is also good practice if only have one >>>>> application per daemon process group, as is recommended, as avoids >>>>> problems with some third party C extensions for Python that will not work >>>>> in Python sub interpreters. >>>>> >>>>>> WSGIProcessGroup dev >>>>> >>>>> This is actually redundant as as process-group option on WSGIScriptAlias. >>>>> >>>>>> WSGIScriptAlias / /usr/local/dev/djangoapp/wsgi.py process-group=dev >>>>>> <Directory /usr/local/dev/djangoapp/> >>>>>> <Files wsgi.py> >>>>>> Require all granted >>>>>> </Files> >>>>>> </Directory> >>>>>> </VirtualHost> >>>>>> -- >>>>>> >>>>>> -- >>>>>> In my vrtualenv: >>>>>> pip freeze gives: >>>>>> Django==1.8.15 >>>>>> mod-wsgi==4.5.7 >>>>>> -- >>>>>> >>>>>> Upon starting httpd as /sbin/service httpd start, I get: >>>>>> ...Adding '/usr/local/dev/env/lib/python3.4/site-packages/' to path >>>>>> ...Target WSGI script '/usr/local/dev/djangoapp/wsgi.py' cannot be >>>>>> loaded as Python module. >>>>>> ...Exception occurred processing WSGI script >>>>>> '/usr/local/dev/djangoapp/wsgi.py' >>>>>> ...from django.core.wsgi import get_wsgi_application >>>>>> ...ImportError: No module named 'django' >>>>>> >>>>>> I greatly appreciate any and all help. I am at my wits' end. mod_wsgi >>>>>> seems to be using the system python interpreter. It is not using the >>>>>> virtualenv appropriately. >>>>> >>>>> So those are things I would recommend, but how you had it should still >>>>> have worked. >>>>> >>>>> What I would suggest is temporarily replace the wsgi.py file with test >>>>> script in: >>>>> >>>>> >>>>> http://modwsgi.readthedocs.io/en/develop/user-guides/checking-your-installation.html#python-installation-in-use >>>>> >>>>> <http://modwsgi.readthedocs.io/en/develop/user-guides/checking-your-installation.html#python-installation-in-use> >>>>> >>>>> This will log some details about the Python virtual environment being >>>>> used. You can then verify is the virtual environment you expect it to be. >>>>> >>>>> Other things to check are that the user that Apache run as has access to >>>>> everything in the virtual environment. That would usually mean access to >>>>> ‘others’ for files and directories. >>>>> >>>>> The only other thing can think of is that SELinux is causing problems, >>>>> but doubt that as it wouldn’t be able to access the wsgi.py even if that >>>>> was the case. >>>>> >>>>> So try that test WSGI script to see if correct virtual environment. Also >>>>> in Python from command line do: >>>>> >>>>> import django >>>>> print(django.__file__) >>>>> >>>>> and see if where Django actually is, corresponds to where you expect it >>>>> to and where mod_wsgi is looking. Modify the test script to print out the >>>>> value of sys.path to see if the directory is in the module search path if >>>>> necessary. >>>>> >>>>> 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 modwsgi+u...@ <>googlegroups.com <http://googlegroups.com/>. >>>>> To post to this group, send email to mod...@ <>googlegroups.com >>>>> <http://googlegroups.com/>. >>>>> Visit this group at https://groups.google.com/group/modwsgi >>>>> <https://groups.google.com/group/modwsgi>. >>>>> For more options, visit https://groups.google.com/d/optout >>>>> <https://groups.google.com/d/optout>. >>>> >>>> >>>> -- >>>> 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 https://groups.google.com/group/modwsgi >>>> <https://groups.google.com/group/modwsgi>. >>>> For more options, visit https://groups.google.com/d/optout >>>> <https://groups.google.com/d/optout>. >>> >> >> >> -- >> 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 https://groups.google.com/group/modwsgi >> <https://groups.google.com/group/modwsgi>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. > > > -- > 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] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/group/modwsgi > <https://groups.google.com/group/modwsgi>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- 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 https://groups.google.com/group/modwsgi. For more options, visit https://groups.google.com/d/optout.
