Linux – Python 2.7.5 and 2.7.13 on Linux; library path conflict with multiple libpython2.7.so

centoscentos7linuxpythonyum

Is there a way to specify a custom dynamic library search path for an executable?

I want /usr/bin/python to reference /usr/lib64/libpython2.7.so and /usr/local/bin/python2.7 to use /usr/local/lib/libpython2.7.so.

Currently, I have Python 2.7.5 as /usr/bin/python (old, used by CentOS) and Python 2.7.13 as /usr/local/bin/python2.7 (new, for development). However, both executables give me Python 2.7.13.

$ /usr/bin/python2.7 --version        # Python 2.7.5
Python 2.7.13                         ← WRONG!!!

$ /usr/local/bin/python2.7 --version  # Python 2.7.13
Python 2.7.13

They are definitely separate executables.

-rwxr-xr-x. 1 root root  7136 Nov  5  2016 /usr/bin/python2.7
-rwxr-xr-x. 1 root root 11368 May 13 18:21 /usr/local/bin/python2.7

This was perplexing until I realized they both dynamically link to libpython2.7.so, and both are searching for it in /usr/local/lib. This was confirmed using ldd. I can get the old Python by modifying /etc/ld.so.conf or $LD_LIBRARY_PATH.

$ LD_LIBRARY_PATH=/usr/lib64 /usr/bin/python --version        # Python 2.7.5
Python 2.7.5

$ LD_LIBRARY_PATH=/usr/lib64 /usr/local/bin/python --version  # Python 2.7.13
Python 2.7.5                                                  ← WRONG!!!

This is a problem because yum depends on the system Python. If I fix that (e.g., by modifying /etc/ld.so.conf), it breaks Python 2.7.13 and things that depend on this newer libpython2.7.so (e.g., Vim with embedded Python). My /etc/ld.so.conf contains /usr/local/lib.

Best Answer

Add this to your .bashrc :

alias yum='LD_LIBRARY_PATH=/usr/lib64 yum'

That will ensure that when running yum (and yum only), the system will search for shared objects (dynamic libraries) first in /usr/lib64 , and not /usr/local/lib. It's a hack, but as far as I can tell, it is unavoidable.

Important: This solution is only applicable if your problem is due to having 2.7.x in /usr/bin and 2.7.y in /usr/local/bin (e.g., 2.7.5 and 2.7.13). If your problem is due to 2.x and 2.y conflicting (e.g., 2.4 and 2.7), then this probably won't help, and might even make things worse for you. Good luck!