Re: [modwsgi] installing mod_wsgi for ucs2 python

2012-07-17 Thread Graham Dumpleton
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

2012-07-17 Thread Graham Dumpleton
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

2012-07-17 Thread Alan Kesselmann
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

2012-07-16 Thread Graham Dumpleton
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

2012-07-10 Thread Alan Kesselmann
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

2012-07-10 Thread Graham Dumpleton
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

2012-07-10 Thread Graham Dumpleton
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

2012-07-10 Thread Alan Kesselmann
*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

2012-07-10 Thread Graham Dumpleton
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

2012-07-09 Thread Graham Dumpleton
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

2012-07-09 Thread Alan Kesselmann
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

2012-07-09 Thread Graham Dumpleton
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

2012-07-09 Thread Alan Kesselmann
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

2012-07-09 Thread Graham Dumpleton
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

2012-07-09 Thread Alan Kesselmann
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

2012-07-09 Thread Graham Dumpleton
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

2012-07-09 Thread Alan Kesselmann
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

2012-07-08 Thread Graham Dumpleton
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