I have an Amazon EC2 instance with Red Hat Linux 7.2 installed. It comes with Python 2.7.5 installed system wide.
I’ve compiled an alternative installation of Python 2.7.8 (which is what I use in another environment that I’m trying to replicate). I will use this to create a virtualenv to launch my Django application.
But invoking python2.7 always takes me to the system-wide python 2.7.5 interpreter.
I followed the instructions at: http://toomuchdata.com/2014/02/16/how-to-install-python-on-centos/
$ sudo yum groupinstall 'development tools' $ sudo yum install zlib-dev openssl-devel sqlite-devel bzip2-devel $ sudo yum install wget $ sudo wget http://www.python.org/ftp/python/2.7.8/Python-2.7.8.tar.xz $ sudo yum install xz-libs $ xz -d Python-2.7.8.tar.xz $ tar -xvf Python-2.7.8.tar $ cd Python-2.7.8
Edited the file /etc/ld.so.conf to add the line
/usr/local/lib $sudo /sbin/ldconfig --> make the dynamic linker aware of the change $sudo ./configure --prefix=/usr/local --enable-unicode=ucs4 --enable-shared $make
I get the following message, but I’m not sure if this is relevant to my problem.
Python build finished, but the necessary bits to build these modules were not found: _bsddb _tkinter bsddb185 dbm dl gdbm imageop sunaudiodev To find the necessary bits, look in setup.py in detect_modules() for the module's name. $sudo make altinstall $which python /usr/bin/python ---> system wide Python 2.7.5 $which python2.7 /usr/local/bin/python2.7 ---> this should point to Python 2.7.8 that was compiled and installed.
But invoking python2.7 points to the system-wide Python 2.7.5 interpreter:
$python2.7 Python 2.7.5 (default, Oct 11 2015, 17:47:16) [GCC 4.8.3 20140911 (Red Hat 4.8.3-9)] on linux2
Why is this happening?
FYI, my PATH does include /usr/local/bin.
$echo $PATH /usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/ec2-user/.local/bin:/home/ec2-user/bin
Advertisement
Answer
Reference: http://koansys.com/tech/building-python-with-enable-shared-in-non-standard-location “I could use “ldd” to add their libraries to the systems cache, and that would work so long as there weren’t any other same-versioned pythons that needed this.”
I fixed my problem by removing the /usr/local/lib from /etc/ld.so.conf and instead specifying LDFLAGS with -rpath option as follows:
$sudo ./configure --prefix=/usr/local/python --enable-unicode=ucs4 --enable-shared LDFLAGS="-Wl,-rpath /usr/local/python/lib"
Note that it is -Wl and not -W1 (ie lower case L and not digit 1). I spent hours figuring out that mistake! Thanks to gcc soname unrecognized command line for pointing this out.
$make $sudo make altinstall
This worked, and invoking the Python interpreter from this path works fine:
$/usr/local/python/bin/python2.7 -- version Python 2.7.8
Most tutorials on the web illustrate how to install two different versions of Python side-by-side eg Python 2.6.x and 2.7.x or Python 2.7.x and 3.3.x.
But when both installations are Python 2.7.x then there seems to be an issue if the path for the custom installation is specified in /etc/ld.so.conf – maybe the libraries being picked up belong to the system default…I still haven’t understood what is going on under the hood.
I also added /usr/local/python/bin to my PATH in .bashrc.
However, in the subsequent steps of installing setuptools, pip, virtualenv and virtualenvwrapper, I still had to explicitly invoke the complete path for python2.7 or pip2.7, otherwise the package is installed in /usr/lib/python2.7/site-packages/ instead of /usr/local/python/lib/python2.7/site-packages.