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 -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 <[email protected]
> <javascript:>> 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 <[email protected]
> <javascript:>> 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
>>
>> 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 <[email protected]> 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
>>> 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
>>>
>>> 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 [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.
>>
>>
>>
> --
> 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] <javascript:>.
> To post to this group, send email to [email protected] <javascript:>
> .
> Visit this group at https://groups.google.com/group/modwsgi.
> For more options, visit 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.
