Re: [modwsgi] installing mod_wsgi for ucs2 python
On 16 July 2012 22:40, Alan Kesselmann alan.kesselm...@gmail.com wrote: Why is it wrong - thats my default 2.7.2 installation that all other sites should work with. It is wrong because WSGIPythonHome is not meant to be set to the name of the Python binary. http://code.google.com/p/modwsgi/wiki/VirtualEnvironments It is meant to be set to the value of sys.prefix for that Python installation. This is only needed if want to refer to a Python installation in a non standard location, or if using a virtual environment. So, if using your Python virtual environment it must be: WSGIPythonHome /home/alan/python/virtualenvs/py273ucs2 You cannot list WSGIPythonHome more than once and you cannot go switching it back to point explicitly, or let it default back to the system wide Python. Especially in your case because the Linux distro have hacked the system wide Python to be incompatible with your self compiled Python installation. A mod_wsgi.so file, even though compiled for 2.7, cannot be used with both your 2.7.2 and 2.7.3 installations. So, you cannot support both Python 2.7.2 (system wide) and 2.7.3 (virtual environment) on the same Apache without also changing the mod_wsgi.so file to an appropriately compiled one, in addition to commenting/uncommenting the different configurations. If you do switch mod_wsgi.so back to one compiled against system wide Python, simply do not set WSGIPythonHome. Graham Since only my testing site should run with the ucs2 python 2.7.3 and all other sites should work with python 2.7.2 i have used this config file to either comment in or out the sites Alias /admin-media/ /home/alan/python/Django-1.3/django/contrib/admin/media/ Directory /home/alan/python/Django-1.3/django/contrib/admin/media Order allow,deny Allow from all /Directory Alias /media/cms/ /home/alan/python/divio-django-cms-3fff03a/cms/media/cms/ Directory /home/alan/python/divio-django-cms-3fff03a/cms/media/cms/ Order allow,deny Allow from all /Directory Alias /media/ /home/alan/projects/pin/media/ Directory /home/alan/projects/pin/media/ #Alias /media/ /home/alan/projects/avalve_v2/media/ #Directory /home/alan/projects/avalve_v2/media/ #Alias /media/ /home/alan/projects/printer/media/ #Directory /home/alan/projects/printer/media/ Order allow,deny Allow from all /Directory WSGIPythonHome /usr/bin/python WSGIPythonPath /usr/local/lib/python2.7/site-packages/ WSGIDaemonProcess pin user=alan group=alan processes=5 threads=1 python-path=/usr/local/lib/python2.7/site-packages/ WSGIProcessGroup pin WSGIScriptAlias / /home/alan/projects/pin/pin.wsgi #WSGIDaemonProcess autovalve user=alan group=alan processes=5 threads=5 #WSGIProcessGroup autovalve #WSGIScriptAlias / /home/alan/projects/avalve_v2/avalve.wsgi #WSGIPythonHome /home/alan/python/virtualenvs/py273ucs2/ #WSGIPythonPath /home/alan/python/virtualenvs/py273ucs2/lib/python2.7/site-packages/ #WSGIDaemonProcess printer user=alan group=alan processes=5 threads=5 python-path=/home/alan/python/virtualenvs/py273ucs2/lib/python2.7/site-packages/ #WSGIProcessGroup printer #WSGIScriptAlias / /home/alan/projects/printer/printer.wsgi Alan On Monday, July 16, 2012 9:10:23 PM UTC+3, Graham Dumpleton wrote: Python home in log should not say /use/bin/python. That is very wrong. That would suggest you have a rouge WSGIPythonHome directive in your Apache config somewhere. Can you check. Graham On 16/07/2012, at 10:25 AM, Alan Kesselmann alan.kesselm...@gmail.com wrote: On Monday, July 16, 2012 5:19:41 PM UTC+3, Graham Dumpleton wrote: Lets summarise where believe things are up to. You have mod_wsgi.so correctly linking in the libpython2.6.so for your own Python installation. This must be mistake (should probably say libpython2.7.so ) because both of the python installations are 2.7. System python was/is 2.7.2 and new installation is 2.7.3. Your virtual environment is constructed using your Python installation. correct You believe you have removed mod_python from your Apache. i have ran sudo aptitude purge libapache2-mod-python. libapache2-mod-wsgi which was installed for initial python still remains. Even though mod_python is not loaded, WSGIPythonHome seems to be getting ignored. This is resulting in system wide Python system .py files to be used on startup. The specific OS you are using doesn't use standard Python code base. Instead they hack it to allow them to have parallel Python standard and debug binaries. Part of this is that they hack the compiled in sys module to have a pydebug flag. The system wide .py files are looking for that flag, but because the libpython2.7.so that is being used is actually from your installation it doesn't have it and fails. this went completely over my head :) Things to do: 1. Please verify this again using: httpd -M Hmm no such command for ubuntu... googled around and found that apache2ctl command should work the same magic:
Re: [modwsgi] installing mod_wsgi for ucs2 python
On 16 July 2012 23:46, Alan Kesselmann alan.kesselm...@gmail.com wrote: Allright... so humm.. do i understand this correctly: if i want to use apache with python 2.7.2 i should also libapache2-mod-wsgi package mod_wsgi.so file? If using distro packaged Python 2.7.2, you must use distro packaged mod_wsgi.so. This is because as I said they have hacked the Python installation and it is not compatible with a Python compiled from source code. Blame the distro people. In my eyes this whole mess started when i wanted to use ucs2 python in my django project while using ucs4 python for all other projects. Why did you feel you needed to do that? FWIW, although Python compiled from source code defaults for UCS2, Linux distros for some reason always build it as UCS4. The MacOS X Python is UCS2 as I believe it is on Windows. Since im not much of a apache/python wizard i figured that virtual environments are magical cure for my problem - fail - apparently not. Nope. Definitely not. You cannot use a constructed virtual environment with a Python installation for a different version or same version but different UCS width. From stackoverflow i was pointed here since it seems that i needed to compile mod_wsgi for my own python also... Correct. For two reasons that distro Python had been hacked and so distro mod_wsgi.so was incompatible with yours, plus that UCS width was different as well. And now that mod_wsgi was not only installed for my ucs2 python but systemwide? Is that it? Don't understand this statement. So whats the whole point of virtual python if its not really virtual at all and forces system wide changes? It doesn't force system wide changes. Your problems came about by your choice not to use standard setup. Reality is that they are simply bound to the Python installation, based on version and UCS width, that you constructed the virtual environment from. It is just how they work and you are trying to do things which aren't normally done. Is it even possible to create really isolated python pockets which contain all necessary modules like mod_wsgi, PIL, postgreqsl support and whatnot? Or so i have to go through this whole mess with each and every module that i compile for this ucs2 python? Why do you really want UCS2? Why can't you simply use the system distro Python? On Linux they likely build for UCS4 for very good reasons so works properly with that Linux or other libraries installed on the system. Too often have seen people do things like you are trying and avoiding the system Python for no good reason. Unless you are experiencing a specific bug with system Python simply use it. Just because it may be a minor patch revision behind would generally not have an affect on the majority of people. I personally still use standard Python 2.6.5 on a MacOS X box and I have no problems living with that. No more for now. I need to sleep. Graham Alan On Tuesday, July 17, 2012 9:11:26 AM UTC+3, Graham Dumpleton wrote: On 16 July 2012 22:40, Alan Kesselmann alan.kesselm...@gmail.com wrote: Why is it wrong - thats my default 2.7.2 installation that all other sites should work with. It is wrong because WSGIPythonHome is not meant to be set to the name of the Python binary. http://code.google.com/p/modwsgi/wiki/VirtualEnvironments It is meant to be set to the value of sys.prefix for that Python installation. This is only needed if want to refer to a Python installation in a non standard location, or if using a virtual environment. So, if using your Python virtual environment it must be: WSGIPythonHome /home/alan/python/virtualenvs/py273ucs2 You cannot list WSGIPythonHome more than once and you cannot go switching it back to point explicitly, or let it default back to the system wide Python. Especially in your case because the Linux distro have hacked the system wide Python to be incompatible with your self compiled Python installation. A mod_wsgi.so file, even though compiled for 2.7, cannot be used with both your 2.7.2 and 2.7.3 installations. So, you cannot support both Python 2.7.2 (system wide) and 2.7.3 (virtual environment) on the same Apache without also changing the mod_wsgi.so file to an appropriately compiled one, in addition to commenting/uncommenting the different configurations. If you do switch mod_wsgi.so back to one compiled against system wide Python, simply do not set WSGIPythonHome. Graham Since only my testing site should run with the ucs2 python 2.7.3 and all other sites should work with python 2.7.2 i have used this config file to either comment in or out the sites Alias /admin-media/ /home/alan/python/Django-1.3/django/contrib/admin/media/ Directory /home/alan/python/Django-1.3/django/contrib/admin/media Order allow,deny Allow from all /Directory Alias /media/cms/ /home/alan/python/divio-django-cms-3fff03a/cms/media/cms/ Directory /home/alan/python/divio-django-cms-3fff03a/cms/media/cms/
Re: [modwsgi] installing mod_wsgi for ucs2 python
Good night, dear sir :) You have been alot of help to me. i greatly appreciate it. Hmmm allright. So if i knew how to switch back to default mod_wsgi.so i could go back and forth between ucs2 and ucs4 pythons? right? Then everything would be sort of fixed i guess. Or i could use ucs2 python everywhere, right? Why i needed ucs2 python is simple - i wanted to test one 3rd party module - http://www.pdftron.com/pdfnet/downloads.html. Unfortunately it is compiled with ucs2 and it did not work with my ucs4 python. I let them know about it and asked if they could provide ucs4 version of their package to me - after lengthy discussion, spanning few weeks i finally got response from them that their guys are all very busy and if i were to buy the licence then they would compile me ucs4 version of their software for me. I would gladly pay those guys for the work they have done, but i just wanted to test their software and see if it works for the project i had in mind. So all that ucs2 python requirement came from there. With your help, Graham, i got this ucs2 python working well enough in my computer that i can crate prototype site with this pdftron software. If all goes well we can pay for the licence and get ucs4 version of the software too... Luckyly my hosting company has ucs2 python installed so hopefully there will be no problems when trying to host the prototype. Alan On Tuesday, July 17, 2012 10:03:14 AM UTC+3, Graham Dumpleton wrote: On 16 July 2012 23:46, Alan Kesselmann alan.kesselm...@gmail.com wrote: Allright... so humm.. do i understand this correctly: if i want to use apache with python 2.7.2 i should also libapache2-mod-wsgi package mod_wsgi.so file? If using distro packaged Python 2.7.2, you must use distro packaged mod_wsgi.so. This is because as I said they have hacked the Python installation and it is not compatible with a Python compiled from source code. Blame the distro people. In my eyes this whole mess started when i wanted to use ucs2 python in my django project while using ucs4 python for all other projects. Why did you feel you needed to do that? FWIW, although Python compiled from source code defaults for UCS2, Linux distros for some reason always build it as UCS4. The MacOS X Python is UCS2 as I believe it is on Windows. Since im not much of a apache/python wizard i figured that virtual environments are magical cure for my problem - fail - apparently not. Nope. Definitely not. You cannot use a constructed virtual environment with a Python installation for a different version or same version but different UCS width. From stackoverflow i was pointed here since it seems that i needed to compile mod_wsgi for my own python also... Correct. For two reasons that distro Python had been hacked and so distro mod_wsgi.so was incompatible with yours, plus that UCS width was different as well. And now that mod_wsgi was not only installed for my ucs2 python but systemwide? Is that it? Don't understand this statement. So whats the whole point of virtual python if its not really virtual at all and forces system wide changes? It doesn't force system wide changes. Your problems came about by your choice not to use standard setup. Reality is that they are simply bound to the Python installation, based on version and UCS width, that you constructed the virtual environment from. It is just how they work and you are trying to do things which aren't normally done. Is it even possible to create really isolated python pockets which contain all necessary modules like mod_wsgi, PIL, postgreqsl support and whatnot? Or so i have to go through this whole mess with each and every module that i compile for this ucs2 python? Why do you really want UCS2? Why can't you simply use the system distro Python? On Linux they likely build for UCS4 for very good reasons so works properly with that Linux or other libraries installed on the system. Too often have seen people do things like you are trying and avoiding the system Python for no good reason. Unless you are experiencing a specific bug with system Python simply use it. Just because it may be a minor patch revision behind would generally not have an affect on the majority of people. I personally still use standard Python 2.6.5 on a MacOS X box and I have no problems living with that. No more for now. I need to sleep. Graham Alan On Tuesday, July 17, 2012 9:11:26 AM UTC+3, Graham Dumpleton wrote: On 16 July 2012 22:40, Alan Kesselmann alan.kesselm...@gmail.com wrote: Why is it wrong - thats my default 2.7.2 installation that all other sites should work with. It is wrong because WSGIPythonHome is not meant to be set to the name of the Python binary. http://code.google.com/p/modwsgi/wiki/VirtualEnvironments It is meant to be set to the
Re: [modwsgi] installing mod_wsgi for ucs2 python
Python home in log should not say /use/bin/python. That is very wrong. That would suggest you have a rouge WSGIPythonHome directive in your Apache config somewhere. Can you check. Graham On 16/07/2012, at 10:25 AM, Alan Kesselmann alan.kesselm...@gmail.com wrote: On Monday, July 16, 2012 5:19:41 PM UTC+3, Graham Dumpleton wrote: Lets summarise where believe things are up to. You have mod_wsgi.so correctly linking in the libpython2.6.so for your own Python installation. This must be mistake (should probably say libpython2.7.so ) because both of the python installations are 2.7. System python was/is 2.7.2 and new installation is 2.7.3. Your virtual environment is constructed using your Python installation. correct You believe you have removed mod_python from your Apache. i have ran sudo aptitude purge libapache2-mod-python. libapache2-mod-wsgi which was installed for initial python still remains. Even though mod_python is not loaded, WSGIPythonHome seems to be getting ignored. This is resulting in system wide Python system .py files to be used on startup. The specific OS you are using doesn't use standard Python code base. Instead they hack it to allow them to have parallel Python standard and debug binaries. Part of this is that they hack the compiled in sys module to have a pydebug flag. The system wide .py files are looking for that flag, but because the libpython2.7.so that is being used is actually from your installation it doesn't have it and fails. this went completely over my head :) Things to do: 1. Please verify this again using: httpd -M Hmm no such command for ubuntu... googled around and found that apache2ctl command should work the same magic: root@alan:/home/alan# apache2ctl -M apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1 for ServerName Loaded Modules: core_module (static) log_config_module (static) logio_module (static) mpm_prefork_module (static) http_module (static) so_module (static) alias_module (shared) auth_basic_module (shared) authn_file_module (shared) authz_default_module (shared) authz_groupfile_module (shared) authz_host_module (shared) authz_user_module (shared) autoindex_module (shared) cgi_module (shared) dav_module (shared) dav_fs_module (shared) deflate_module (shared) dir_module (shared) env_module (shared) include_module (shared) mime_module (shared) negotiation_module (shared) php5_module (shared) reqtimeout_module (shared) rewrite_module (shared) ruby_module (shared) setenvif_module (shared) ssl_module (shared) status_module (shared) suexec_module (shared) wsgi_module (shared) Syntax OK root@alan:/home/alan# or by looking at the 'pldd' equivalent that mod_python is not being loaded, as this prevents WSGIPythonHome from working. 2. Set LogLevel to 'debug' in Apache at global scope so that mod_wsgi logs extra details. This extra detail should include when it is overriding Python home based on WSGIPythonHome. Changed. i get more/different stuff in error.log now. Spam like this: [Mon Jul 16 20:14:10 2012] [info] mod_wsgi (pid=5052): Process 'pin' has died, restarting. [Mon Jul 16 20:14:10 2012] [info] mod_wsgi (pid=5056): Starting process 'pin' with uid=1000, gid=1000 and threads=1. [Mon Jul 16 20:14:10 2012] [info] mod_wsgi (pid=5056): Python home /usr/bin/python. [Mon Jul 16 20:14:10 2012] [info] mod_wsgi (pid=5056): Initializing Python. [Mon Jul 16 20:14:10 2012] [info] mod_wsgi (pid=5053): Process 'pin' has died, restarting. [Mon Jul 16 20:14:10 2012] [info] mod_wsgi (pid=5054): Process 'pin' has died, restarting. [Mon Jul 16 20:14:10 2012] [info] mod_wsgi (pid=5059): Starting process 'pin' with uid=1000, gid=1000 and threads=1. [Mon Jul 16 20:14:10 2012] [info] mod_wsgi (pid=5058): Starting process 'pin' with uid=1000, gid=1000 and threads=1. ImportError: No module named site [Mon Jul 16 20:14:10 2012] [info] mod_wsgi (pid=5059): Python home /usr/bin/python. [Mon Jul 16 20:14:10 2012] [info] mod_wsgi (pid=5058): Python home /usr/bin/python. [Mon Jul 16 20:14:10 2012] [info] mod_wsgi (pid=5059): Initializing Python. [Mon Jul 16 20:14:10 2012] [info] mod_wsgi (pid=5058): Initializing Python. ImportError: No module named site [Mon Jul 16 20:14:10 2012] [info] mod_wsgi (pid=5057): Starting process 'pin' with uid=1000, gid=1000 and threads=1. ImportError: No module named site ImportError: No module named site [Mon Jul 16 20:14:10 2012] [info] mod_wsgi (pid=5057): Python home /usr/bin/python. [Mon Jul 16 20:14:10 2012] [info] mod_wsgi (pid=5057): Initializing Python. ImportError: No module named site 3. Try and set the environment variable: PYTHONVERBOSE=1 export PYTHONVERBOSE in the 'envvars' file for Apache, or if that doesn't exist in same directory as 'httpd' binary, use
Re: [modwsgi] installing mod_wsgi for ucs2 python
so i took my time and read carefully though the wiki about checking my installation so it looks like it should be working. I did what the wiki says and: alan@alan:~$ unset LD_LIBRARY_PATH alan@alan:~$ ldd /usr/lib/apache2/modules/mod_wsgi.so linux-vdso.so.1 = (0x7fff6e1f7000) libpython2.7.so.1.0 = /opt/lib/libpython2.7.so.1.0 (0x7f5aa1cb1000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f5aa1a7) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f5aa16ce000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f5aa14ca000) libutil.so.1 = /lib/x86_64-linux-gnu/libutil.so.1 (0x7f5aa12c7000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f5aa1042000) /lib64/ld-linux-x86-64.so.2 (0x7f5aa22b9000) alan@alan:~$ locate mod_wsgi.so /home/alan/python/modwsgi/mod_wsgi-3.3/.libs/mod_wsgi.so /usr/lib/apache2/modules/mod_wsgi.so /usr/lib/apache2/modules/mod_wsgi.so-2.6 /usr/lib/apache2/modules/mod_wsgi.so-2.7 alan@alan:~$ cd /home/alan/python/modwsgi/mod_wsgi-3.3/ alan@alan:~/python/modwsgi/mod_wsgi-3.3$ ldd .libs/mod_wsgi.so linux-vdso.so.1 = (0x75d5f000) libpython2.7.so.1.0 = /opt/lib/libpython2.7.so.1.0 (0x7fc8018ff000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fc8016be000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7fc80131c000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7fc801118000) libutil.so.1 = /lib/x86_64-linux-gnu/libutil.so.1 (0x7fc800f15000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7fc800c9) /lib64/ld-linux-x86-64.so.2 (0x7fc801f07000) So is it safe to say now, that mod_wsgi installation is not the problem? If yes, then i guess we could continue this on stackoverflow where it started at. Alan On Monday, July 9, 2012 2:48:23 PM UTC+3, Alan Kesselmann wrote: alan@alan:/usr/lib/apache2/modules$ ldd mod_wsgi.so linux-vdso.so.1 = (0x7fff497ff000) libpython2.7.so.1.0 = /opt/lib/libpython2.7.so.1.0 (0x7fdc404d5000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fdc40294000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7fdc3fef2000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7fdc3fcee000) libutil.so.1 = /lib/x86_64-linux-gnu/libutil.so.1 (0x7fdc3faeb000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7fdc3f866000) /lib64/ld-linux-x86-64.so.2 (0x7fdc40add000) Alan On Monday, July 9, 2012 2:42:18 PM UTC+3, Graham Dumpleton wrote: On 9 July 2012 21:39, Alan Kesselmann alan.kesselm...@gmail.com wrote: Hmmm.. ldd /opt/bin/python prints out : alan@alan:/opt/lib/python2.7$ ldd /opt/bin/python linux-vdso.so.1 = (0x7fff4818c000) libpython2.7.so.1.0 = /opt/lib/libpython2.7.so.1.0 (0x7f6bf236e000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f6bf212d000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f6bf1d8b000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f6bf1b87000) libutil.so.1 = /lib/x86_64-linux-gnu/libutil.so.1 (0x7f6bf1984000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f6bf16ff000) /lib64/ld-linux-x86-64.so.2 (0x7f6bf2748000) Idd .libs/mod_wsgi prints out ldd: .libs/mod_wsgi: No such file or directory Sorry, should have been: ldd .libs/mod_wsgi.so That or run it on the installed mod_wsgi.so in Apache modules directory. Graham and ldd mod_wsgi.so prints ldd: ./mod_wsgi.so: No such file or directory so things arent as rosy as i thought, eh? Alan On Monday, July 9, 2012 2:20:26 PM UTC+3, Graham Dumpleton wrote: Sort of looks like the virtual environment you are pointing mod_wsgi at was constructed using Python 2.7.2 and not Python 2.7.3. Try some of the checks starting at: http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Python_Shared_Library Graham On 9 July 2012 20:59, Alan Kesselmann alan.kesselm...@gmail.com wrote: Awesome! Thanks Graham! Both modules installed successfully and virtualenv too. At first apache wouldnt start but after restarting computer it works too now. This didnt fix my original problem ( http://stackoverflow.com/questions/11382024/python-version-virtualenvwrapper-and-django), but at least its working :) Thanks again :) Alan On Monday, July 9, 2012 1:04:14 PM UTC+3, Graham Dumpleton wrote: On 9 July 2012 18:37, Alan Kesselmann alan.kesselm...@gmail.com wrote: So let me get this straight so i dont do it rial and error way for 1 hour: 1) unpack 2.7.3. 2 ) LD_RUN_PATH=/opt/lib 3) export $LD_RUN_PATH No '$'. Just: export LD_RUN_PATH Make sure also run at this point: make distclean to make sure you don't have any old build results laying around. 4) ./configure --enable-shared --prefix=/opt --enable-unicode=ucs2 5) make 6 )
Re: [modwsgi] installing mod_wsgi for ucs2 python
Can continue here. But in a bit over a day I will be on a plane for a day, so don't expect quick answers then. :-) On 10 July 2012 16:47, Alan Kesselmann alan.kesselm...@gmail.com wrote: so i took my time and read carefully though the wiki about checking my installation so it looks like it should be working. I did what the wiki says and: alan@alan:~$ unset LD_LIBRARY_PATH alan@alan:~$ ldd /usr/lib/apache2/modules/mod_wsgi.so linux-vdso.so.1 = (0x7fff6e1f7000) libpython2.7.so.1.0 = /opt/lib/libpython2.7.so.1.0 (0x7f5aa1cb1000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f5aa1a7) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f5aa16ce000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f5aa14ca000) libutil.so.1 = /lib/x86_64-linux-gnu/libutil.so.1 (0x7f5aa12c7000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f5aa1042000) /lib64/ld-linux-x86-64.so.2 (0x7f5aa22b9000) alan@alan:~$ locate mod_wsgi.so /home/alan/python/modwsgi/mod_wsgi-3.3/.libs/mod_wsgi.so /usr/lib/apache2/modules/mod_wsgi.so /usr/lib/apache2/modules/mod_wsgi.so-2.6 /usr/lib/apache2/modules/mod_wsgi.so-2.7 alan@alan:~$ cd /home/alan/python/modwsgi/mod_wsgi-3.3/ alan@alan:~/python/modwsgi/mod_wsgi-3.3$ ldd .libs/mod_wsgi.so linux-vdso.so.1 = (0x75d5f000) libpython2.7.so.1.0 = /opt/lib/libpython2.7.so.1.0 (0x7fc8018ff000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fc8016be000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7fc80131c000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7fc801118000) libutil.so.1 = /lib/x86_64-linux-gnu/libutil.so.1 (0x7fc800f15000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7fc800c9) /lib64/ld-linux-x86-64.so.2 (0x7fc801f07000) So is it safe to say now, that mod_wsgi installation is not the problem? If yes, then i guess we could continue this on stackoverflow where it started at. Alan On Monday, July 9, 2012 2:48:23 PM UTC+3, Alan Kesselmann wrote: alan@alan:/usr/lib/apache2/modules$ ldd mod_wsgi.so linux-vdso.so.1 = (0x7fff497ff000) libpython2.7.so.1.0 = /opt/lib/libpython2.7.so.1.0 (0x7fdc404d5000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fdc40294000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7fdc3fef2000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7fdc3fcee000) libutil.so.1 = /lib/x86_64-linux-gnu/libutil.so.1 (0x7fdc3faeb000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7fdc3f866000) /lib64/ld-linux-x86-64.so.2 (0x7fdc40add000) Alan On Monday, July 9, 2012 2:42:18 PM UTC+3, Graham Dumpleton wrote: On 9 July 2012 21:39, Alan Kesselmann alan.kesselm...@gmail.com wrote: Hmmm.. ldd /opt/bin/python prints out : alan@alan:/opt/lib/python2.7$ ldd /opt/bin/python linux-vdso.so.1 = (0x7fff4818c000) libpython2.7.so.1.0 = /opt/lib/libpython2.7.so.1.0 (0x7f6bf236e000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f6bf212d000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f6bf1d8b000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f6bf1b87000) libutil.so.1 = /lib/x86_64-linux-gnu/libutil.so.1 (0x7f6bf1984000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f6bf16ff000) /lib64/ld-linux-x86-64.so.2 (0x7f6bf2748000) Idd .libs/mod_wsgi prints out ldd: .libs/mod_wsgi: No such file or directory Sorry, should have been: ldd .libs/mod_wsgi.so That or run it on the installed mod_wsgi.so in Apache modules directory. Graham and ldd mod_wsgi.so prints ldd: ./mod_wsgi.so: No such file or directory so things arent as rosy as i thought, eh? Alan On Monday, July 9, 2012 2:20:26 PM UTC+3, Graham Dumpleton wrote: Sort of looks like the virtual environment you are pointing mod_wsgi at was constructed using Python 2.7.2 and not Python 2.7.3. Try some of the checks starting at: http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Python_Shared_Library Graham On 9 July 2012 20:59, Alan Kesselmann alan.kesselm...@gmail.com wrote: Awesome! Thanks Graham! Both modules installed successfully and virtualenv too. At first apache wouldnt start but after restarting computer it works too now. This didnt fix my original problem ( http://stackoverflow.com/questions/11382024/python-version-virtualenvwrapper-and-django), but at least its working :) Thanks again :) Alan On Monday, July 9, 2012 1:04:14 PM UTC+3, Graham Dumpleton wrote: On 9 July 2012 18:37, Alan Kesselmann alan.kesselm...@gmail.com wrote: So let me get this straight so i dont do it rial and error way for 1 hour: 1) unpack 2.7.3. 2 ) LD_RUN_PATH=/opt/lib 3) export $LD_RUN_PATH No '$'. Just: export LD_RUN_PATH Make sure also run at this point: make distclean to make sure you don't
Re: [modwsgi] installing mod_wsgi for ucs2 python
What is the current problem after fixing Python and mod_wsgi installations? Did you ensure you recreated your virtual environments using the newly installed Python? Send the latest errors you get. Graham On 10 July 2012 17:06, Alan Kesselmann alan.kesselm...@gmail.com wrote: No problem man - you have already been huge help. Much more i could have expected. We can continue here yeah - i would just copy solution to stackoverflow also so the answer would be easyer to find for future generations :) So if the mod_wsgi installation is working fine what could be the problem then? my httpd.conf perhaps : Alias /admin-media/ /home/alan/python/Django-1.3/django/contrib/admin/media/ Directory /home/alan/python/Django-1.3/django/contrib/admin/media Order allow,deny Allow from all /Directory Alias /media/cms/ /home/alan/python/divio-django-cms-3fff03a/cms/media/cms/ Directory /home/alan/python/divio-django-cms-3fff03a/cms/media/cms/ Order allow,deny Allow from all /Directory Alias /media/ /home/alan/projects/printer/media Directory /home/alan/projects/printer/media/ Order allow,deny Allow from all /Directory WSGIPythonHome /home/alan/python/virtualenvs/py273ucs2 WSGIPythonPath /home/alan/python/virtualenvs/py273ucs2/lib/python2.7/site-packages WSGIDaemonProcess printer user=alan group=alan processes=5 threads=5 python-path=/home/alan/python/virtualenvs/py273ucs2/lib/python2.7/site-packages WSGIProcessGroup printer WSGIScriptAlias / /home/alan/projects/printer/printer.wsgi Alan On Tuesday, July 10, 2012 10:00:22 AM UTC+3, Graham Dumpleton wrote: Can continue here. But in a bit over a day I will be on a plane for a day, so don't expect quick answers then. :-) On 10 July 2012 16:47, Alan Kesselmann alan.kesselm...@gmail.com wrote: so i took my time and read carefully though the wiki about checking my installation so it looks like it should be working. I did what the wiki says and: alan@alan:~$ unset LD_LIBRARY_PATH alan@alan:~$ ldd /usr/lib/apache2/modules/mod_wsgi.so linux-vdso.so.1 = (0x7fff6e1f7000) libpython2.7.so.1.0 = /opt/lib/libpython2.7.so.1.0 (0x7f5aa1cb1000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f5aa1a7) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f5aa16ce000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f5aa14ca000) libutil.so.1 = /lib/x86_64-linux-gnu/libutil.so.1 (0x7f5aa12c7000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f5aa1042000) /lib64/ld-linux-x86-64.so.2 (0x7f5aa22b9000) alan@alan:~$ locate mod_wsgi.so /home/alan/python/modwsgi/mod_wsgi-3.3/.libs/mod_wsgi.so /usr/lib/apache2/modules/mod_wsgi.so /usr/lib/apache2/modules/mod_wsgi.so-2.6 /usr/lib/apache2/modules/mod_wsgi.so-2.7 alan@alan:~$ cd /home/alan/python/modwsgi/mod_wsgi-3.3/ alan@alan:~/python/modwsgi/mod_wsgi-3.3$ ldd .libs/mod_wsgi.so linux-vdso.so.1 = (0x75d5f000) libpython2.7.so.1.0 = /opt/lib/libpython2.7.so.1.0 (0x7fc8018ff000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fc8016be000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7fc80131c000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7fc801118000) libutil.so.1 = /lib/x86_64-linux-gnu/libutil.so.1 (0x7fc800f15000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7fc800c9) /lib64/ld-linux-x86-64.so.2 (0x7fc801f07000) So is it safe to say now, that mod_wsgi installation is not the problem? If yes, then i guess we could continue this on stackoverflow where it started at. Alan On Monday, July 9, 2012 2:48:23 PM UTC+3, Alan Kesselmann wrote: alan@alan:/usr/lib/apache2/modules$ ldd mod_wsgi.so linux-vdso.so.1 = (0x7fff497ff000) libpython2.7.so.1.0 = /opt/lib/libpython2.7.so.1.0 (0x7fdc404d5000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fdc40294000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7fdc3fef2000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7fdc3fcee000) libutil.so.1 = /lib/x86_64-linux-gnu/libutil.so.1 (0x7fdc3faeb000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7fdc3f866000) /lib64/ld-linux-x86-64.so.2 (0x7fdc40add000) Alan On Monday, July 9, 2012 2:42:18 PM UTC+3, Graham Dumpleton wrote: On 9 July 2012 21:39, Alan Kesselmann alan.kesselm...@gmail.com wrote: Hmmm.. ldd /opt/bin/python prints out : alan@alan:/opt/lib/python2.7$ ldd /opt/bin/python linux-vdso.so.1 = (0x7fff4818c000) libpython2.7.so.1.0 = /opt/lib/libpython2.7.so.1.0 (0x7f6bf236e000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f6bf212d000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f6bf1d8b000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f6bf1b87000) libutil.so.1 = /lib/x86_64-linux-gnu/libutil.so.1 (0x7f6bf1984000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6
Re: [modwsgi] installing mod_wsgi for ucs2 python
*Did all that just now:* alan@alan:~$ sudo uninstall virtualenvwrapper [sudo] password for alan: sudo: uninstall: command not found alan@alan:~$ sudo pip uninstall virtualenvwrapper Uninstalling virtualenvwrapper: /usr/local/bin/virtualenvwrapper.sh /usr/local/bin/virtualenvwrapper_lazy.sh /usr/local/lib/python2.7/dist-packages/virtualenvwrapper-3.5-nspkg.pth /usr/local/lib/python2.7/dist-packages/virtualenvwrapper-3.5.egg-info /usr/local/lib/python2.7/dist-packages/virtualenvwrapper/hook_loader.py /usr/local/lib/python2.7/dist-packages/virtualenvwrapper/hook_loader.pyc /usr/local/lib/python2.7/dist-packages/virtualenvwrapper/project.py /usr/local/lib/python2.7/dist-packages/virtualenvwrapper/project.pyc /usr/local/lib/python2.7/dist-packages/virtualenvwrapper/user_scripts.py /usr/local/lib/python2.7/dist-packages/virtualenvwrapper/user_scripts.pyc Proceed (y/n)? y Successfully uninstalled virtualenvwrapper alan@alan:~$ sudo pip uninstall virtualenv Uninstalling virtualenv: /usr/local/bin/virtualenv /usr/local/bin/virtualenv-2.7 /usr/local/lib/python2.7/dist-packages/virtualenv-1.7.2.egg-info /usr/local/lib/python2.7/dist-packages/virtualenv.py /usr/local/lib/python2.7/dist-packages/virtualenv.pyc /usr/local/lib/python2.7/dist-packages/virtualenv_support Proceed (y/n)? y Successfully uninstalled virtualenv alan@alan:~$ rm /home/alan/python/virtualenvs/py273ucs2/ -Rf alan@alan:~$ ls -l /home/alan/python/virtualenvs/ total 72 -rwxrwxr-x 1 alan alan 106 2012-07-08 11:34 get_env_details -rw-rw-r-- 1 alan alan 1828 2012-07-10 09:31 hook.log -rw-rw-r-- 1 alan alan 10206 2012-07-09 16:10 hook.log.1 -rwxrwxr-x 1 alan alan92 2012-07-08 11:34 initialize -rwxrwxr-x 1 alan alan69 2012-07-08 11:34 postactivate -rwxrwxr-x 1 alan alan71 2012-07-08 11:34 postdeactivate -rwxrwxr-x 1 alan alan66 2012-07-08 11:34 postmkproject -rwxrwxr-x 1 alan alan69 2012-07-08 11:34 postmkvirtualenv -rwxrwxr-x 1 alan alan60 2012-07-08 11:34 postrmproject -rwxrwxr-x 1 alan alan63 2012-07-08 11:34 postrmvirtualenv -rwxrwxr-x 1 alan alan70 2012-07-08 11:34 preactivate -rwxrwxr-x 1 alan alan72 2012-07-08 11:34 predeactivate -rwxrwxr-x 1 alan alan91 2012-07-08 11:34 premkproject -rwxrwxr-x 1 alan alan94 2012-07-08 11:34 premkvirtualenv -rwxrwxr-x 1 alan alan61 2012-07-08 11:34 prermproject -rwxrwxr-x 1 alan alan64 2012-07-08 11:34 prermvirtualenv alan@alan:~$ sudo pip install virtualenv Downloading/unpacking virtualenv Downloading virtualenv-1.7.2.tar.gz (2.2Mb): 2.2Mb downloaded Running setup.py egg_info for package virtualenv warning: no previously-included files matching '*' found under directory 'docs/_templates' warning: no previously-included files matching '*' found under directory 'docs/_build' Installing collected packages: virtualenv Running setup.py install for virtualenv warning: no previously-included files matching '*' found under directory 'docs/_templates' warning: no previously-included files matching '*' found under directory 'docs/_build' Installing virtualenv script to /usr/local/bin Installing virtualenv-2.7 script to /usr/local/bin Successfully installed virtualenv Cleaning up... alan@alan:~$ sudo pip install virtualenv Requirement already satisfied (use --upgrade to upgrade): virtualenv in /usr/local/lib/python2.7/dist-packages Cleaning up... alan@alan:~$ sudo pip install virtualenvwrapper Downloading/unpacking virtualenvwrapper Downloading virtualenvwrapper-3.5.tar.gz (465Kb): 465Kb downloaded Running setup.py egg_info for package virtualenvwrapper Requirement already satisfied (use --upgrade to upgrade): virtualenv in /usr/local/lib/python2.7/dist-packages (from virtualenvwrapper) Requirement already satisfied (use --upgrade to upgrade): virtualenv-clone in /usr/local/lib/python2.7/dist-packages (from virtualenvwrapper) Installing collected packages: virtualenvwrapper Running setup.py install for virtualenvwrapper changing mode of build/scripts-2.7/virtualenvwrapper.sh from 644 to 755 changing mode of build/scripts-2.7/virtualenvwrapper_lazy.sh from 644 to 755 Skipping installation of /usr/local/lib/python2.7/dist-packages/virtualenvwrapper/__init__.py (namespace package) Installing /usr/local/lib/python2.7/dist-packages/virtualenvwrapper-3.5-nspkg.pth changing mode of /usr/local/bin/virtualenvwrapper_lazy.sh to 755 changing mode of /usr/local/bin/virtualenvwrapper.sh to 755 Successfully installed virtualenvwrapper Cleaning up... alan@alan:~$ *Then i added this to .bashrc* export WORKON_HOME=/home/alan/python/virtualenvs source /usr/local/bin/virtualenvwrapper.sh export PIP_VIRTUALENV_BASE=$WORKON_HOME export PIP_RESPECT_VIRTUALENV=true *opened new shell and then:* alan@alan:~$ mkvirtualenv --no-site-packages --python=/opt/bin/python py273ucs2 Running virtualenv with interpreter /opt/bin/python The --no-site-packages flag is
Re: [modwsgi] installing mod_wsgi for ucs2 python
Run 'pldd' on one of the process IDs of Apache once started. May need to be root. This will tell you what libpython Apache is actually using. On 10 July 2012 21:01, Alan Kesselmann alan.kesselm...@gmail.com wrote: Did all that just now: alan@alan:~$ sudo uninstall virtualenvwrapper [sudo] password for alan: sudo: uninstall: command not found alan@alan:~$ sudo pip uninstall virtualenvwrapper Uninstalling virtualenvwrapper: /usr/local/bin/virtualenvwrapper.sh /usr/local/bin/virtualenvwrapper_lazy.sh /usr/local/lib/python2.7/dist-packages/virtualenvwrapper-3.5-nspkg.pth /usr/local/lib/python2.7/dist-packages/virtualenvwrapper-3.5.egg-info /usr/local/lib/python2.7/dist-packages/virtualenvwrapper/hook_loader.py /usr/local/lib/python2.7/dist-packages/virtualenvwrapper/hook_loader.pyc /usr/local/lib/python2.7/dist-packages/virtualenvwrapper/project.py /usr/local/lib/python2.7/dist-packages/virtualenvwrapper/project.pyc /usr/local/lib/python2.7/dist-packages/virtualenvwrapper/user_scripts.py /usr/local/lib/python2.7/dist-packages/virtualenvwrapper/user_scripts.pyc Proceed (y/n)? y Successfully uninstalled virtualenvwrapper alan@alan:~$ sudo pip uninstall virtualenv Uninstalling virtualenv: /usr/local/bin/virtualenv /usr/local/bin/virtualenv-2.7 /usr/local/lib/python2.7/dist-packages/virtualenv-1.7.2.egg-info /usr/local/lib/python2.7/dist-packages/virtualenv.py /usr/local/lib/python2.7/dist-packages/virtualenv.pyc /usr/local/lib/python2.7/dist-packages/virtualenv_support Proceed (y/n)? y Successfully uninstalled virtualenv alan@alan:~$ rm /home/alan/python/virtualenvs/py273ucs2/ -Rf alan@alan:~$ ls -l /home/alan/python/virtualenvs/ total 72 -rwxrwxr-x 1 alan alan 106 2012-07-08 11:34 get_env_details -rw-rw-r-- 1 alan alan 1828 2012-07-10 09:31 hook.log -rw-rw-r-- 1 alan alan 10206 2012-07-09 16:10 hook.log.1 -rwxrwxr-x 1 alan alan92 2012-07-08 11:34 initialize -rwxrwxr-x 1 alan alan69 2012-07-08 11:34 postactivate -rwxrwxr-x 1 alan alan71 2012-07-08 11:34 postdeactivate -rwxrwxr-x 1 alan alan66 2012-07-08 11:34 postmkproject -rwxrwxr-x 1 alan alan69 2012-07-08 11:34 postmkvirtualenv -rwxrwxr-x 1 alan alan60 2012-07-08 11:34 postrmproject -rwxrwxr-x 1 alan alan63 2012-07-08 11:34 postrmvirtualenv -rwxrwxr-x 1 alan alan70 2012-07-08 11:34 preactivate -rwxrwxr-x 1 alan alan72 2012-07-08 11:34 predeactivate -rwxrwxr-x 1 alan alan91 2012-07-08 11:34 premkproject -rwxrwxr-x 1 alan alan94 2012-07-08 11:34 premkvirtualenv -rwxrwxr-x 1 alan alan61 2012-07-08 11:34 prermproject -rwxrwxr-x 1 alan alan64 2012-07-08 11:34 prermvirtualenv alan@alan:~$ sudo pip install virtualenv Downloading/unpacking virtualenv Downloading virtualenv-1.7.2.tar.gz (2.2Mb): 2.2Mb downloaded Running setup.py egg_info for package virtualenv warning: no previously-included files matching '*' found under directory 'docs/_templates' warning: no previously-included files matching '*' found under directory 'docs/_build' Installing collected packages: virtualenv Running setup.py install for virtualenv warning: no previously-included files matching '*' found under directory 'docs/_templates' warning: no previously-included files matching '*' found under directory 'docs/_build' Installing virtualenv script to /usr/local/bin Installing virtualenv-2.7 script to /usr/local/bin Successfully installed virtualenv Cleaning up... alan@alan:~$ sudo pip install virtualenv Requirement already satisfied (use --upgrade to upgrade): virtualenv in /usr/local/lib/python2.7/dist-packages Cleaning up... alan@alan:~$ sudo pip install virtualenvwrapper Downloading/unpacking virtualenvwrapper Downloading virtualenvwrapper-3.5.tar.gz (465Kb): 465Kb downloaded Running setup.py egg_info for package virtualenvwrapper Requirement already satisfied (use --upgrade to upgrade): virtualenv in /usr/local/lib/python2.7/dist-packages (from virtualenvwrapper) Requirement already satisfied (use --upgrade to upgrade): virtualenv-clone in /usr/local/lib/python2.7/dist-packages (from virtualenvwrapper) Installing collected packages: virtualenvwrapper Running setup.py install for virtualenvwrapper changing mode of build/scripts-2.7/virtualenvwrapper.sh from 644 to 755 changing mode of build/scripts-2.7/virtualenvwrapper_lazy.sh from 644 to 755 Skipping installation of /usr/local/lib/python2.7/dist-packages/virtualenvwrapper/__init__.py (namespace package) Installing /usr/local/lib/python2.7/dist-packages/virtualenvwrapper-3.5-nspkg.pth changing mode of /usr/local/bin/virtualenvwrapper_lazy.sh to 755 changing mode of /usr/local/bin/virtualenvwrapper.sh to 755 Successfully installed virtualenvwrapper Cleaning up... alan@alan:~$ Then i added this to .bashrc export WORKON_HOME=/home/alan/python/virtualenvs source /usr/local/bin/virtualenvwrapper.sh
Re: [modwsgi] installing mod_wsgi for ucs2 python
This is occurring because you have a Python 2.7 installed in a system location as well. Why aren't you using the system Python 2.7? To get around this issue, when building Python and also mod_wsgi. Set: LD_RUN_PATH=/opt/lib export LD_RUN_PATH This only needs to be set when they are compiled, not at run time. This will force each to look in /opt/lib for the shared library, rather than giving precedence to the system wide Python. Graham On 9 July 2012 18:15, Alan Kesselmann alan.kesselm...@gmail.com wrote: Hi and thanks for reply. Can you give me exact order or things i need to do when installing? Im asking cause this --enable-shared is giving weird results if i do: things i such order: 1) uncompress the 2.7.3 package 2) ./configure --enable-shared --prefix=/opt --enable-unicode=ucs2 3) make 4) make install If i go to /opt/bin and type ./python then i get old python version (2.7.2) not new one. If i leave --enable shared out i get new 2.7.3 when i do ./python in /opt/bin Im new to all this thing and im only doing this compiling to get one library working with ucs2 python and django - so im not even what the hell is going on here :P alan On Monday, July 9, 2012 1:41:31 AM UTC+3, Graham Dumpleton wrote: The problem is that your Python installation was not configured to install a shared library for Python. That is, when 'configure' was run in Python source code when it was being installed, the '--enable-shared' option was not used. If you are using a binary Python installation then there isn't anything you can do but complain to the people who make the binary distribution. If you compiled Python from source code, you need to reinstall it from virgin source code (make distclean) and this time also use '--enable-shared' when running 'configure' on Python source code before running 'make'. So, it is all about your Python installation. Once you have fixed the Python installation, do a 'make distclean' in mod_wsgi source code and try rebuilding it against the reinstalled Python. Graham On 9 July 2012 00:41, Alan Kesselmann alan.kesselm...@gmail.com wrote: Hello. My long search (https://groups.google.com/forum/?fromgroups#!topic/comp.lang.python/bGuAfqa76W8, http://stackoverflow.com/questions/11382024/python-version-virtualenvwrapper-and-django) has brought me here. Long story short - it seems i need to install mod_wsgi for my 2nd python installation which is 2.7.3 ucs 2. What i did was: alan@alan:~/python/modwsgi$ wget http://modwsgi.googlecode.com/files/mod_wsgi-3.3.tar.gz --2012-07-08 17:33:27-- http://modwsgi.googlecode.com/files/mod_wsgi-3.3.tar.gz Resolving modwsgi.googlecode.com... 173.194.67.82, 2a00:1450:4001:c01::52 Connecting to modwsgi.googlecode.com|173.194.67.82|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 117930 (115K) [application/x-gzip] Saving to: `mod_wsgi-3.3.tar.gz' 100%[==] 117,930 319K/s in 0.4s 2012-07-08 17:33:28 (319 KB/s) - `mod_wsgi-3.3.tar.gz' saved [117930/117930] alan@alan:~/python/modwsgi$ tar xvfz mod_wsgi-3.3.tar.gz mod_wsgi-3.3/ mod_wsgi-3.3/configure mod_wsgi-3.3/configure.ac mod_wsgi-3.3/LICENCE mod_wsgi-3.3/mod_wsgi.c mod_wsgi-3.3/posix-ap1X.mk.in mod_wsgi-3.3/posix-ap2X.mk.in mod_wsgi-3.3/README mod_wsgi-3.3/win32-ap22py26.mk mod_wsgi-3.3/win32-ap22py31.mk alan@alan:~/python/modwsgi$ cd mod_wsgi-3.3/ alan@alan:~/python/modwsgi/mod_wsgi-3.3$ ./configure --with-python=/opt/bin/python checking for apxs2... /usr/bin/apxs2 checking Apache version... 2.2.20 configure: creating ./config.status config.status: creating Makefile And what i got was: alan@alan:~/python/modwsgi/mod_wsgi-3.3$ make /usr/bin/apxs2 -c -I/opt/include/python2.7 -DNDEBUG mod_wsgi.c -L/opt/lib -L/opt/lib/python2.7/config -lpython2.7 -lpthread -ldl -lutil -lm /usr/share/apr-1.0/build/libtool --silent --mode=compile --tag=disable-static x86_64-linux-gnu-gcc -prefer-pic -DLINUX=2 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_REENTRANT -I/usr/include/apr-1.0 -I/usr/include/openssl -I/usr/include/xmltok -pthread -I/usr/include/apache2 -I/usr/include/apr-1.0 -I/usr/include/apr-1.0 -I/opt/include/python2.7 -DNDEBUG -c -o mod_wsgi.lo mod_wsgi.c touch mod_wsgi.slo In file included from /opt/include/python2.7/Python.h:8:0, from mod_wsgi.c:135: /opt/include/python2.7/pyconfig.h:1161:0: warning: _POSIX_C_SOURCE redefined [enabled by default] /usr/include/features.h:163:0: note: this is the location of the previous definition /opt/include/python2.7/pyconfig.h:1183:0: warning: _XOPEN_SOURCE redefined [enabled by default] /usr/include/features.h:165:0: note: this is the location of the previous definition /usr/share/apr-1.0/build/libtool --silent --mode=link --tag=disable-static
Re: [modwsgi] installing mod_wsgi for ucs2 python
So let me get this straight so i dont do it rial and error way for 1 hour: 1) unpack 2.7.3. 2 ) LD_RUN_PATH=/opt/lib 3) export $LD_RUN_PATH 4) ./configure --enable-shared --prefix=/opt --enable-unicode=ucs2 5) make 6 ) make install? And yes - i have python 2.7.2 installed and im installing 2.7.3 because i need ucs2 python for one precompiled library. Alan On Monday, July 9, 2012 11:29:02 AM UTC+3, Graham Dumpleton wrote: This is occurring because you have a Python 2.7 installed in a system location as well. Why aren't you using the system Python 2.7? To get around this issue, when building Python and also mod_wsgi. Set: LD_RUN_PATH=/opt/lib export LD_RUN_PATH This only needs to be set when they are compiled, not at run time. This will force each to look in /opt/lib for the shared library, rather than giving precedence to the system wide Python. Graham On 9 July 2012 18:15, Alan Kesselmann alan.kesselm...@gmail.com wrote: Hi and thanks for reply. Can you give me exact order or things i need to do when installing? Im asking cause this --enable-shared is giving weird results if i do: things i such order: 1) uncompress the 2.7.3 package 2) ./configure --enable-shared --prefix=/opt --enable-unicode=ucs2 3) make 4) make install If i go to /opt/bin and type ./python then i get old python version (2.7.2) not new one. If i leave --enable shared out i get new 2.7.3 when i do ./python in /opt/bin Im new to all this thing and im only doing this compiling to get one library working with ucs2 python and django - so im not even what the hell is going on here :P alan On Monday, July 9, 2012 1:41:31 AM UTC+3, Graham Dumpleton wrote: The problem is that your Python installation was not configured to install a shared library for Python. That is, when 'configure' was run in Python source code when it was being installed, the '--enable-shared' option was not used. If you are using a binary Python installation then there isn't anything you can do but complain to the people who make the binary distribution. If you compiled Python from source code, you need to reinstall it from virgin source code (make distclean) and this time also use '--enable-shared' when running 'configure' on Python source code before running 'make'. So, it is all about your Python installation. Once you have fixed the Python installation, do a 'make distclean' in mod_wsgi source code and try rebuilding it against the reinstalled Python. Graham On 9 July 2012 00:41, Alan Kesselmann alan.kesselm...@gmail.com wrote: Hello. My long search ( https://groups.google.com/forum/?fromgroups#!topic/comp.lang.python/bGuAfqa76W8, http://stackoverflow.com/questions/11382024/python-version-virtualenvwrapper-and-django) has brought me here. Long story short - it seems i need to install mod_wsgi for my 2nd python installation which is 2.7.3 ucs 2. What i did was: alan@alan:~/python/modwsgi$ wget http://modwsgi.googlecode.com/files/mod_wsgi-3.3.tar.gz --2012-07-08 17:33:27-- http://modwsgi.googlecode.com/files/mod_wsgi-3.3.tar.gz Resolving modwsgi.googlecode.com... 173.194.67.82, 2a00:1450:4001:c01::52 Connecting to modwsgi.googlecode.com|173.194.67.82|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 117930 (115K) [application/x-gzip] Saving to: `mod_wsgi-3.3.tar.gz' 100%[==] 117,930 319K/s in 0.4s 2012-07-08 17:33:28 (319 KB/s) - `mod_wsgi-3.3.tar.gz' saved [117930/117930] alan@alan:~/python/modwsgi$ tar xvfz mod_wsgi-3.3.tar.gz mod_wsgi-3.3/ mod_wsgi-3.3/configure mod_wsgi-3.3/configure.ac mod_wsgi-3.3/LICENCE mod_wsgi-3.3/mod_wsgi.c mod_wsgi-3.3/posix-ap1X.mk.in mod_wsgi-3.3/posix-ap2X.mk.in mod_wsgi-3.3/README mod_wsgi-3.3/win32-ap22py26.mk mod_wsgi-3.3/win32-ap22py31.mk alan@alan:~/python/modwsgi$ cd mod_wsgi-3.3/ alan@alan:~/python/modwsgi/mod_wsgi-3.3$ ./configure --with-python=/opt/bin/python checking for apxs2... /usr/bin/apxs2 checking Apache version... 2.2.20 configure: creating ./config.status config.status: creating Makefile And what i got was: alan@alan:~/python/modwsgi/mod_wsgi-3.3$ make /usr/bin/apxs2 -c -I/opt/include/python2.7 -DNDEBUG mod_wsgi.c -L/opt/lib -L/opt/lib/python2.7/config -lpython2.7 -lpthread -ldl -lutil -lm /usr/share/apr-1.0/build/libtool --silent --mode=compile --tag=disable-static x86_64-linux-gnu-gcc -prefer-pic -DLINUX=2 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_REENTRANT -I/usr/include/apr-1.0 -I/usr/include/openssl -I/usr/include/xmltok -pthread -I/usr/include/apache2 -I/usr/include/apr-1.0
Re: [modwsgi] installing mod_wsgi for ucs2 python
On 9 July 2012 18:37, Alan Kesselmann alan.kesselm...@gmail.com wrote: So let me get this straight so i dont do it rial and error way for 1 hour: 1) unpack 2.7.3. 2 ) LD_RUN_PATH=/opt/lib 3) export $LD_RUN_PATH No '$'. Just: export LD_RUN_PATH Make sure also run at this point: make distclean to make sure you don't have any old build results laying around. 4) ./configure --enable-shared --prefix=/opt --enable-unicode=ucs2 5) make 6 ) make install? And then in mod_wsgi source code: make distclean ./configure --with-python=/opt/bin/python make make install If things worked properly, when you run: ldd /opt/bin/python ldd .libs/mod_wsgi The latter in mod_wsgo source directory after 'make', then you should see a dependency on your shared library and not the system one. And yes - i have python 2.7.2 installed and im installing 2.7.3 because i need ucs2 python for one precompiled library. Alan On Monday, July 9, 2012 11:29:02 AM UTC+3, Graham Dumpleton wrote: This is occurring because you have a Python 2.7 installed in a system location as well. Why aren't you using the system Python 2.7? To get around this issue, when building Python and also mod_wsgi. Set: LD_RUN_PATH=/opt/lib export LD_RUN_PATH This only needs to be set when they are compiled, not at run time. This will force each to look in /opt/lib for the shared library, rather than giving precedence to the system wide Python. Graham On 9 July 2012 18:15, Alan Kesselmann alan.kesselm...@gmail.com wrote: Hi and thanks for reply. Can you give me exact order or things i need to do when installing? Im asking cause this --enable-shared is giving weird results if i do: things i such order: 1) uncompress the 2.7.3 package 2) ./configure --enable-shared --prefix=/opt --enable-unicode=ucs2 3) make 4) make install If i go to /opt/bin and type ./python then i get old python version (2.7.2) not new one. If i leave --enable shared out i get new 2.7.3 when i do ./python in /opt/bin Im new to all this thing and im only doing this compiling to get one library working with ucs2 python and django - so im not even what the hell is going on here :P alan On Monday, July 9, 2012 1:41:31 AM UTC+3, Graham Dumpleton wrote: The problem is that your Python installation was not configured to install a shared library for Python. That is, when 'configure' was run in Python source code when it was being installed, the '--enable-shared' option was not used. If you are using a binary Python installation then there isn't anything you can do but complain to the people who make the binary distribution. If you compiled Python from source code, you need to reinstall it from virgin source code (make distclean) and this time also use '--enable-shared' when running 'configure' on Python source code before running 'make'. So, it is all about your Python installation. Once you have fixed the Python installation, do a 'make distclean' in mod_wsgi source code and try rebuilding it against the reinstalled Python. Graham On 9 July 2012 00:41, Alan Kesselmann alan.kesselm...@gmail.com wrote: Hello. My long search (https://groups.google.com/forum/?fromgroups#!topic/comp.lang.python/bGuAfqa76W8, http://stackoverflow.com/questions/11382024/python-version-virtualenvwrapper-and-django) has brought me here. Long story short - it seems i need to install mod_wsgi for my 2nd python installation which is 2.7.3 ucs 2. What i did was: alan@alan:~/python/modwsgi$ wget http://modwsgi.googlecode.com/files/mod_wsgi-3.3.tar.gz --2012-07-08 17:33:27-- http://modwsgi.googlecode.com/files/mod_wsgi-3.3.tar.gz Resolving modwsgi.googlecode.com... 173.194.67.82, 2a00:1450:4001:c01::52 Connecting to modwsgi.googlecode.com|173.194.67.82|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 117930 (115K) [application/x-gzip] Saving to: `mod_wsgi-3.3.tar.gz' 100%[==] 117,930 319K/s in 0.4s 2012-07-08 17:33:28 (319 KB/s) - `mod_wsgi-3.3.tar.gz' saved [117930/117930] alan@alan:~/python/modwsgi$ tar xvfz mod_wsgi-3.3.tar.gz mod_wsgi-3.3/ mod_wsgi-3.3/configure mod_wsgi-3.3/configure.ac mod_wsgi-3.3/LICENCE mod_wsgi-3.3/mod_wsgi.c mod_wsgi-3.3/posix-ap1X.mk.in mod_wsgi-3.3/posix-ap2X.mk.in mod_wsgi-3.3/README mod_wsgi-3.3/win32-ap22py26.mk mod_wsgi-3.3/win32-ap22py31.mk alan@alan:~/python/modwsgi$ cd mod_wsgi-3.3/ alan@alan:~/python/modwsgi/mod_wsgi-3.3$ ./configure --with-python=/opt/bin/python checking for apxs2... /usr/bin/apxs2 checking Apache version... 2.2.20 configure: creating ./config.status config.status: creating Makefile And what i got was: alan@alan:~/python/modwsgi/mod_wsgi-3.3$ make /usr/bin/apxs2 -c
Re: [modwsgi] installing mod_wsgi for ucs2 python
Awesome! Thanks Graham! Both modules installed successfully and virtualenv too. At first apache wouldnt start but after restarting computer it works too now. This didnt fix my original problem ( http://stackoverflow.com/questions/11382024/python-version-virtualenvwrapper-and-django), but at least its working :) Thanks again :) Alan On Monday, July 9, 2012 1:04:14 PM UTC+3, Graham Dumpleton wrote: On 9 July 2012 18:37, Alan Kesselmann alan.kesselm...@gmail.com wrote: So let me get this straight so i dont do it rial and error way for 1 hour: 1) unpack 2.7.3. 2 ) LD_RUN_PATH=/opt/lib 3) export $LD_RUN_PATH No '$'. Just: export LD_RUN_PATH Make sure also run at this point: make distclean to make sure you don't have any old build results laying around. 4) ./configure --enable-shared --prefix=/opt --enable-unicode=ucs2 5) make 6 ) make install? And then in mod_wsgi source code: make distclean ./configure --with-python=/opt/bin/python make make install If things worked properly, when you run: ldd /opt/bin/python ldd .libs/mod_wsgi The latter in mod_wsgo source directory after 'make', then you should see a dependency on your shared library and not the system one. And yes - i have python 2.7.2 installed and im installing 2.7.3 because i need ucs2 python for one precompiled library. Alan On Monday, July 9, 2012 11:29:02 AM UTC+3, Graham Dumpleton wrote: This is occurring because you have a Python 2.7 installed in a system location as well. Why aren't you using the system Python 2.7? To get around this issue, when building Python and also mod_wsgi. Set: LD_RUN_PATH=/opt/lib export LD_RUN_PATH This only needs to be set when they are compiled, not at run time. This will force each to look in /opt/lib for the shared library, rather than giving precedence to the system wide Python. Graham On 9 July 2012 18:15, Alan Kesselmann alan.kesselm...@gmail.com wrote: Hi and thanks for reply. Can you give me exact order or things i need to do when installing? Im asking cause this --enable-shared is giving weird results if i do: things i such order: 1) uncompress the 2.7.3 package 2) ./configure --enable-shared --prefix=/opt --enable-unicode=ucs2 3) make 4) make install If i go to /opt/bin and type ./python then i get old python version (2.7.2) not new one. If i leave --enable shared out i get new 2.7.3 when i do ./python in /opt/bin Im new to all this thing and im only doing this compiling to get one library working with ucs2 python and django - so im not even what the hell is going on here :P alan On Monday, July 9, 2012 1:41:31 AM UTC+3, Graham Dumpleton wrote: The problem is that your Python installation was not configured to install a shared library for Python. That is, when 'configure' was run in Python source code when it was being installed, the '--enable-shared' option was not used. If you are using a binary Python installation then there isn't anything you can do but complain to the people who make the binary distribution. If you compiled Python from source code, you need to reinstall it from virgin source code (make distclean) and this time also use '--enable-shared' when running 'configure' on Python source code before running 'make'. So, it is all about your Python installation. Once you have fixed the Python installation, do a 'make distclean' in mod_wsgi source code and try rebuilding it against the reinstalled Python. Graham On 9 July 2012 00:41, Alan Kesselmann alan.kesselm...@gmail.com wrote: Hello. My long search ( https://groups.google.com/forum/?fromgroups#!topic/comp.lang.python/bGuAfqa76W8, http://stackoverflow.com/questions/11382024/python-version-virtualenvwrapper-and-django) has brought me here. Long story short - it seems i need to install mod_wsgi for my 2nd python installation which is 2.7.3 ucs 2. What i did was: alan@alan:~/python/modwsgi$ wget http://modwsgi.googlecode.com/files/mod_wsgi-3.3.tar.gz --2012-07-08 17:33:27-- http://modwsgi.googlecode.com/files/mod_wsgi-3.3.tar.gz Resolving modwsgi.googlecode.com... 173.194.67.82, 2a00:1450:4001:c01::52 Connecting to modwsgi.googlecode.com|173.194.67.82|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 117930 (115K) [application/x-gzip] Saving to: `mod_wsgi-3.3.tar.gz' 100%[==] 117,930 319K/s in 0.4s 2012-07-08 17:33:28 (319 KB/s) - `mod_wsgi-3.3.tar.gz' saved [117930/117930]
Re: [modwsgi] installing mod_wsgi for ucs2 python
Sort of looks like the virtual environment you are pointing mod_wsgi at was constructed using Python 2.7.2 and not Python 2.7.3. Try some of the checks starting at: http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Python_Shared_Library Graham On 9 July 2012 20:59, Alan Kesselmann alan.kesselm...@gmail.com wrote: Awesome! Thanks Graham! Both modules installed successfully and virtualenv too. At first apache wouldnt start but after restarting computer it works too now. This didnt fix my original problem ( http://stackoverflow.com/questions/11382024/python-version-virtualenvwrapper-and-django), but at least its working :) Thanks again :) Alan On Monday, July 9, 2012 1:04:14 PM UTC+3, Graham Dumpleton wrote: On 9 July 2012 18:37, Alan Kesselmann alan.kesselm...@gmail.com wrote: So let me get this straight so i dont do it rial and error way for 1 hour: 1) unpack 2.7.3. 2 ) LD_RUN_PATH=/opt/lib 3) export $LD_RUN_PATH No '$'. Just: export LD_RUN_PATH Make sure also run at this point: make distclean to make sure you don't have any old build results laying around. 4) ./configure --enable-shared --prefix=/opt --enable-unicode=ucs2 5) make 6 ) make install? And then in mod_wsgi source code: make distclean ./configure --with-python=/opt/bin/python make make install If things worked properly, when you run: ldd /opt/bin/python ldd .libs/mod_wsgi The latter in mod_wsgo source directory after 'make', then you should see a dependency on your shared library and not the system one. And yes - i have python 2.7.2 installed and im installing 2.7.3 because i need ucs2 python for one precompiled library. Alan On Monday, July 9, 2012 11:29:02 AM UTC+3, Graham Dumpleton wrote: This is occurring because you have a Python 2.7 installed in a system location as well. Why aren't you using the system Python 2.7? To get around this issue, when building Python and also mod_wsgi. Set: LD_RUN_PATH=/opt/lib export LD_RUN_PATH This only needs to be set when they are compiled, not at run time. This will force each to look in /opt/lib for the shared library, rather than giving precedence to the system wide Python. Graham On 9 July 2012 18:15, Alan Kesselmann alan.kesselm...@gmail.com wrote: Hi and thanks for reply. Can you give me exact order or things i need to do when installing? Im asking cause this --enable-shared is giving weird results if i do: things i such order: 1) uncompress the 2.7.3 package 2) ./configure --enable-shared --prefix=/opt --enable-unicode=ucs2 3) make 4) make install If i go to /opt/bin and type ./python then i get old python version (2.7.2) not new one. If i leave --enable shared out i get new 2.7.3 when i do ./python in /opt/bin Im new to all this thing and im only doing this compiling to get one library working with ucs2 python and django - so im not even what the hell is going on here :P alan On Monday, July 9, 2012 1:41:31 AM UTC+3, Graham Dumpleton wrote: The problem is that your Python installation was not configured to install a shared library for Python. That is, when 'configure' was run in Python source code when it was being installed, the '--enable-shared' option was not used. If you are using a binary Python installation then there isn't anything you can do but complain to the people who make the binary distribution. If you compiled Python from source code, you need to reinstall it from virgin source code (make distclean) and this time also use '--enable-shared' when running 'configure' on Python source code before running 'make'. So, it is all about your Python installation. Once you have fixed the Python installation, do a 'make distclean' in mod_wsgi source code and try rebuilding it against the reinstalled Python. Graham On 9 July 2012 00:41, Alan Kesselmann alan.kesselm...@gmail.com wrote: Hello. My long search (https://groups.google.com/forum/?fromgroups#!topic/comp.lang.python/bGuAfqa76W8, http://stackoverflow.com/questions/11382024/python-version-virtualenvwrapper-and-django) has brought me here. Long story short - it seems i need to install mod_wsgi for my 2nd python installation which is 2.7.3 ucs 2. What i did was: alan@alan:~/python/modwsgi$ wget http://modwsgi.googlecode.com/files/mod_wsgi-3.3.tar.gz --2012-07-08 17:33:27-- http://modwsgi.googlecode.com/files/mod_wsgi-3.3.tar.gz Resolving modwsgi.googlecode.com... 173.194.67.82, 2a00:1450:4001:c01::52 Connecting to modwsgi.googlecode.com|173.194.67.82|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 117930 (115K) [application/x-gzip] Saving to: `mod_wsgi-3.3.tar.gz'
Re: [modwsgi] installing mod_wsgi for ucs2 python
Hmmm.. ldd /opt/bin/python prints out : alan@alan:/opt/lib/python2.7$ ldd /opt/bin/python linux-vdso.so.1 = (0x7fff4818c000) libpython2.7.so.1.0 = /opt/lib/libpython2.7.so.1.0 (0x7f6bf236e000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f6bf212d000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f6bf1d8b000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f6bf1b87000) libutil.so.1 = /lib/x86_64-linux-gnu/libutil.so.1 (0x7f6bf1984000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f6bf16ff000) /lib64/ld-linux-x86-64.so.2 (0x7f6bf2748000) Idd .libs/mod_wsgi prints out ldd: .libs/mod_wsgi: No such file or directory and ldd mod_wsgi.so prints ldd: ./mod_wsgi.so: No such file or directory so things arent as rosy as i thought, eh? Alan On Monday, July 9, 2012 2:20:26 PM UTC+3, Graham Dumpleton wrote: Sort of looks like the virtual environment you are pointing mod_wsgi at was constructed using Python 2.7.2 and not Python 2.7.3. Try some of the checks starting at: http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Python_Shared_Library Graham On 9 July 2012 20:59, Alan Kesselmann alan.kesselm...@gmail.com wrote: Awesome! Thanks Graham! Both modules installed successfully and virtualenv too. At first apache wouldnt start but after restarting computer it works too now. This didnt fix my original problem ( http://stackoverflow.com/questions/11382024/python-version-virtualenvwrapper-and-django), but at least its working :) Thanks again :) Alan On Monday, July 9, 2012 1:04:14 PM UTC+3, Graham Dumpleton wrote: On 9 July 2012 18:37, Alan Kesselmann alan.kesselm...@gmail.com wrote: So let me get this straight so i dont do it rial and error way for 1 hour: 1) unpack 2.7.3. 2 ) LD_RUN_PATH=/opt/lib 3) export $LD_RUN_PATH No '$'. Just: export LD_RUN_PATH Make sure also run at this point: make distclean to make sure you don't have any old build results laying around. 4) ./configure --enable-shared --prefix=/opt --enable-unicode=ucs2 5) make 6 ) make install? And then in mod_wsgi source code: make distclean ./configure --with-python=/opt/bin/python make make install If things worked properly, when you run: ldd /opt/bin/python ldd .libs/mod_wsgi The latter in mod_wsgo source directory after 'make', then you should see a dependency on your shared library and not the system one. And yes - i have python 2.7.2 installed and im installing 2.7.3 because i need ucs2 python for one precompiled library. Alan On Monday, July 9, 2012 11:29:02 AM UTC+3, Graham Dumpleton wrote: This is occurring because you have a Python 2.7 installed in a system location as well. Why aren't you using the system Python 2.7? To get around this issue, when building Python and also mod_wsgi. Set: LD_RUN_PATH=/opt/lib export LD_RUN_PATH This only needs to be set when they are compiled, not at run time. This will force each to look in /opt/lib for the shared library, rather than giving precedence to the system wide Python. Graham On 9 July 2012 18:15, Alan Kesselmann alan.kesselm...@gmail.com wrote: Hi and thanks for reply. Can you give me exact order or things i need to do when installing? Im asking cause this --enable-shared is giving weird results if i do: things i such order: 1) uncompress the 2.7.3 package 2) ./configure --enable-shared --prefix=/opt --enable-unicode=ucs2 3) make 4) make install If i go to /opt/bin and type ./python then i get old python version (2.7.2) not new one. If i leave --enable shared out i get new 2.7.3 when i do ./python in /opt/bin Im new to all this thing and im only doing this compiling to get one library working with ucs2 python and django - so im not even what the hell is going on here :P alan On Monday, July 9, 2012 1:41:31 AM UTC+3, Graham Dumpleton wrote: The problem is that your Python installation was not configured to install a shared library for Python. That is, when 'configure' was run in Python source code when it was being installed, the '--enable-shared' option was not used. If you are using a binary Python installation then there isn't anything you can do but complain to the people who make the binary distribution. If you compiled Python from source code, you need to reinstall it from virgin source code (make distclean) and this time also use '--enable-shared' when running 'configure' on Python source code before running 'make'. So, it is all about your Python installation. Once you
Re: [modwsgi] installing mod_wsgi for ucs2 python
On 9 July 2012 21:39, Alan Kesselmann alan.kesselm...@gmail.com wrote: Hmmm.. ldd /opt/bin/python prints out : alan@alan:/opt/lib/python2.7$ ldd /opt/bin/python linux-vdso.so.1 = (0x7fff4818c000) libpython2.7.so.1.0 = /opt/lib/libpython2.7.so.1.0 (0x7f6bf236e000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f6bf212d000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f6bf1d8b000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f6bf1b87000) libutil.so.1 = /lib/x86_64-linux-gnu/libutil.so.1 (0x7f6bf1984000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f6bf16ff000) /lib64/ld-linux-x86-64.so.2 (0x7f6bf2748000) Idd .libs/mod_wsgi prints out ldd: .libs/mod_wsgi: No such file or directory Sorry, should have been: ldd .libs/mod_wsgi.so That or run it on the installed mod_wsgi.so in Apache modules directory. Graham and ldd mod_wsgi.so prints ldd: ./mod_wsgi.so: No such file or directory so things arent as rosy as i thought, eh? Alan On Monday, July 9, 2012 2:20:26 PM UTC+3, Graham Dumpleton wrote: Sort of looks like the virtual environment you are pointing mod_wsgi at was constructed using Python 2.7.2 and not Python 2.7.3. Try some of the checks starting at: http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Python_Shared_Library Graham On 9 July 2012 20:59, Alan Kesselmann alan.kesselm...@gmail.com wrote: Awesome! Thanks Graham! Both modules installed successfully and virtualenv too. At first apache wouldnt start but after restarting computer it works too now. This didnt fix my original problem ( http://stackoverflow.com/questions/11382024/python-version-virtualenvwrapper-and-django), but at least its working :) Thanks again :) Alan On Monday, July 9, 2012 1:04:14 PM UTC+3, Graham Dumpleton wrote: On 9 July 2012 18:37, Alan Kesselmann alan.kesselm...@gmail.com wrote: So let me get this straight so i dont do it rial and error way for 1 hour: 1) unpack 2.7.3. 2 ) LD_RUN_PATH=/opt/lib 3) export $LD_RUN_PATH No '$'. Just: export LD_RUN_PATH Make sure also run at this point: make distclean to make sure you don't have any old build results laying around. 4) ./configure --enable-shared --prefix=/opt --enable-unicode=ucs2 5) make 6 ) make install? And then in mod_wsgi source code: make distclean ./configure --with-python=/opt/bin/python make make install If things worked properly, when you run: ldd /opt/bin/python ldd .libs/mod_wsgi The latter in mod_wsgo source directory after 'make', then you should see a dependency on your shared library and not the system one. And yes - i have python 2.7.2 installed and im installing 2.7.3 because i need ucs2 python for one precompiled library. Alan On Monday, July 9, 2012 11:29:02 AM UTC+3, Graham Dumpleton wrote: This is occurring because you have a Python 2.7 installed in a system location as well. Why aren't you using the system Python 2.7? To get around this issue, when building Python and also mod_wsgi. Set: LD_RUN_PATH=/opt/lib export LD_RUN_PATH This only needs to be set when they are compiled, not at run time. This will force each to look in /opt/lib for the shared library, rather than giving precedence to the system wide Python. Graham On 9 July 2012 18:15, Alan Kesselmann alan.kesselm...@gmail.com wrote: Hi and thanks for reply. Can you give me exact order or things i need to do when installing? Im asking cause this --enable-shared is giving weird results if i do: things i such order: 1) uncompress the 2.7.3 package 2) ./configure --enable-shared --prefix=/opt --enable-unicode=ucs2 3) make 4) make install If i go to /opt/bin and type ./python then i get old python version (2.7.2) not new one. If i leave --enable shared out i get new 2.7.3 when i do ./python in /opt/bin Im new to all this thing and im only doing this compiling to get one library working with ucs2 python and django - so im not even what the hell is going on here :P alan On Monday, July 9, 2012 1:41:31 AM UTC+3, Graham Dumpleton wrote: The problem is that your Python installation was not configured to install a shared library for Python. That is, when 'configure' was run in Python source code when it was being installed, the '--enable-shared' option was not used. If you are using a binary Python installation then there isn't anything you can do but complain to the people who make the binary distribution. If you compiled Python from source code, you need to reinstall it from virgin source code (make distclean) and this time also use '--enable-shared' when running 'configure' on
Re: [modwsgi] installing mod_wsgi for ucs2 python
alan@alan:/usr/lib/apache2/modules$ ldd mod_wsgi.so linux-vdso.so.1 = (0x7fff497ff000) libpython2.7.so.1.0 = /opt/lib/libpython2.7.so.1.0 (0x7fdc404d5000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fdc40294000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7fdc3fef2000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7fdc3fcee000) libutil.so.1 = /lib/x86_64-linux-gnu/libutil.so.1 (0x7fdc3faeb000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7fdc3f866000) /lib64/ld-linux-x86-64.so.2 (0x7fdc40add000) Alan On Monday, July 9, 2012 2:42:18 PM UTC+3, Graham Dumpleton wrote: On 9 July 2012 21:39, Alan Kesselmann alan.kesselm...@gmail.com wrote: Hmmm.. ldd /opt/bin/python prints out : alan@alan:/opt/lib/python2.7$ ldd /opt/bin/python linux-vdso.so.1 = (0x7fff4818c000) libpython2.7.so.1.0 = /opt/lib/libpython2.7.so.1.0 (0x7f6bf236e000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f6bf212d000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f6bf1d8b000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f6bf1b87000) libutil.so.1 = /lib/x86_64-linux-gnu/libutil.so.1 (0x7f6bf1984000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f6bf16ff000) /lib64/ld-linux-x86-64.so.2 (0x7f6bf2748000) Idd .libs/mod_wsgi prints out ldd: .libs/mod_wsgi: No such file or directory Sorry, should have been: ldd .libs/mod_wsgi.so That or run it on the installed mod_wsgi.so in Apache modules directory. Graham and ldd mod_wsgi.so prints ldd: ./mod_wsgi.so: No such file or directory so things arent as rosy as i thought, eh? Alan On Monday, July 9, 2012 2:20:26 PM UTC+3, Graham Dumpleton wrote: Sort of looks like the virtual environment you are pointing mod_wsgi at was constructed using Python 2.7.2 and not Python 2.7.3. Try some of the checks starting at: http://code.google.com/p/modwsgi/wiki/CheckingYourInstallation#Python_Shared_Library Graham On 9 July 2012 20:59, Alan Kesselmann alan.kesselm...@gmail.com wrote: Awesome! Thanks Graham! Both modules installed successfully and virtualenv too. At first apache wouldnt start but after restarting computer it works too now. This didnt fix my original problem ( http://stackoverflow.com/questions/11382024/python-version-virtualenvwrapper-and-django), but at least its working :) Thanks again :) Alan On Monday, July 9, 2012 1:04:14 PM UTC+3, Graham Dumpleton wrote: On 9 July 2012 18:37, Alan Kesselmann alan.kesselm...@gmail.com wrote: So let me get this straight so i dont do it rial and error way for 1 hour: 1) unpack 2.7.3. 2 ) LD_RUN_PATH=/opt/lib 3) export $LD_RUN_PATH No '$'. Just: export LD_RUN_PATH Make sure also run at this point: make distclean to make sure you don't have any old build results laying around. 4) ./configure --enable-shared --prefix=/opt --enable-unicode=ucs2 5) make 6 ) make install? And then in mod_wsgi source code: make distclean ./configure --with-python=/opt/bin/python make make install If things worked properly, when you run: ldd /opt/bin/python ldd .libs/mod_wsgi The latter in mod_wsgo source directory after 'make', then you should see a dependency on your shared library and not the system one. And yes - i have python 2.7.2 installed and im installing 2.7.3 because i need ucs2 python for one precompiled library. Alan On Monday, July 9, 2012 11:29:02 AM UTC+3, Graham Dumpleton wrote: This is occurring because you have a Python 2.7 installed in a system location as well. Why aren't you using the system Python 2.7? To get around this issue, when building Python and also mod_wsgi. Set: LD_RUN_PATH=/opt/lib export LD_RUN_PATH This only needs to be set when they are compiled, not at run time. This will force each to look in /opt/lib for the shared library, rather than giving precedence to the system wide Python. Graham On 9 July 2012 18:15, Alan Kesselmann alan.kesselm...@gmail.com wrote: Hi and thanks for reply. Can you give me exact order or things i need to do when installing? Im asking cause this --enable-shared is giving weird results if i do: things i such order: 1) uncompress the 2.7.3 package 2) ./configure --enable-shared --prefix=/opt --enable-unicode=ucs2 3) make 4) make install If i go to /opt/bin and type ./python then i get old python version (2.7.2) not new one. If i leave --enable shared out i get new 2.7.3
Re: [modwsgi] installing mod_wsgi for ucs2 python
The problem is that your Python installation was not configured to install a shared library for Python. That is, when 'configure' was run in Python source code when it was being installed, the '--enable-shared' option was not used. If you are using a binary Python installation then there isn't anything you can do but complain to the people who make the binary distribution. If you compiled Python from source code, you need to reinstall it from virgin source code (make distclean) and this time also use '--enable-shared' when running 'configure' on Python source code before running 'make'. So, it is all about your Python installation. Once you have fixed the Python installation, do a 'make distclean' in mod_wsgi source code and try rebuilding it against the reinstalled Python. Graham On 9 July 2012 00:41, Alan Kesselmann alan.kesselm...@gmail.com wrote: Hello. My long search (https://groups.google.com/forum/?fromgroups#!topic/comp.lang.python/bGuAfqa76W8, http://stackoverflow.com/questions/11382024/python-version-virtualenvwrapper-and-django) has brought me here. Long story short - it seems i need to install mod_wsgi for my 2nd python installation which is 2.7.3 ucs 2. What i did was: alan@alan:~/python/modwsgi$ wget http://modwsgi.googlecode.com/files/mod_wsgi-3.3.tar.gz --2012-07-08 17:33:27-- http://modwsgi.googlecode.com/files/mod_wsgi-3.3.tar.gz Resolving modwsgi.googlecode.com... 173.194.67.82, 2a00:1450:4001:c01::52 Connecting to modwsgi.googlecode.com|173.194.67.82|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 117930 (115K) [application/x-gzip] Saving to: `mod_wsgi-3.3.tar.gz' 100%[==] 117,930 319K/s in 0.4s 2012-07-08 17:33:28 (319 KB/s) - `mod_wsgi-3.3.tar.gz' saved [117930/117930] alan@alan:~/python/modwsgi$ tar xvfz mod_wsgi-3.3.tar.gz mod_wsgi-3.3/ mod_wsgi-3.3/configure mod_wsgi-3.3/configure.ac mod_wsgi-3.3/LICENCE mod_wsgi-3.3/mod_wsgi.c mod_wsgi-3.3/posix-ap1X.mk.in mod_wsgi-3.3/posix-ap2X.mk.in mod_wsgi-3.3/README mod_wsgi-3.3/win32-ap22py26.mk mod_wsgi-3.3/win32-ap22py31.mk alan@alan:~/python/modwsgi$ cd mod_wsgi-3.3/ alan@alan:~/python/modwsgi/mod_wsgi-3.3$ ./configure --with-python=/opt/bin/python checking for apxs2... /usr/bin/apxs2 checking Apache version... 2.2.20 configure: creating ./config.status config.status: creating Makefile And what i got was: alan@alan:~/python/modwsgi/mod_wsgi-3.3$ make /usr/bin/apxs2 -c -I/opt/include/python2.7 -DNDEBUG mod_wsgi.c -L/opt/lib -L/opt/lib/python2.7/config -lpython2.7 -lpthread -ldl -lutil -lm /usr/share/apr-1.0/build/libtool --silent --mode=compile --tag=disable-static x86_64-linux-gnu-gcc -prefer-pic -DLINUX=2 -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -D_REENTRANT -I/usr/include/apr-1.0 -I/usr/include/openssl -I/usr/include/xmltok -pthread -I/usr/include/apache2 -I/usr/include/apr-1.0 -I/usr/include/apr-1.0 -I/opt/include/python2.7 -DNDEBUG -c -o mod_wsgi.lo mod_wsgi.c touch mod_wsgi.slo In file included from /opt/include/python2.7/Python.h:8:0, from mod_wsgi.c:135: /opt/include/python2.7/pyconfig.h:1161:0: warning: _POSIX_C_SOURCE redefined [enabled by default] /usr/include/features.h:163:0: note: this is the location of the previous definition /opt/include/python2.7/pyconfig.h:1183:0: warning: _XOPEN_SOURCE redefined [enabled by default] /usr/include/features.h:165:0: note: this is the location of the previous definition /usr/share/apr-1.0/build/libtool --silent --mode=link --tag=disable-static x86_64-linux-gnu-gcc -o mod_wsgi.la -rpath /usr/lib/apache2/modules -module -avoid-versionmod_wsgi.lo -L/opt/lib -L/opt/lib/python2.7/config -lpython2.7 -lpthread -ldl -lutil -lm /usr/bin/ld: /opt/lib/libpython2.7.a(abstract.o): relocation R_X86_64_32S against `_Py_NotImplementedStruct' can not be used when making a shared object; recompile with -fPIC /opt/lib/libpython2.7.a: could not read symbols: Bad value collect2: ld returned 1 exit status apxs:Error: Command failed with rc=65536 . make: *** [mod_wsgi.la] Error 1 Can someone help me understand whats wrong here and tell me what do i need to do to get this stuff up and running for once :) Alan -- 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/-/WC1J-sGDT_oJ. To post to this group, send email to modwsgi@googlegroups.com. To unsubscribe from this group, send email to modwsgi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en. -- You received this message because you are subscribed to the Google Groups modwsgi group. To post to this group, send email to modwsgi@googlegroups.com. To unsubscribe from this group, send email to modwsgi+unsubscr...@googlegroups.com. For more options, visit this