Issue with installing Python 2.7.8 alongside 2.7.5 on RHEL 7.2

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

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.