Building Python 2.6 as shared library broke (after previously working), any reason why?

I'm on a VPS running CentOS, with has Python 2.4 installed - which unfortunately means that I have to avoid breaking it. So I'm installing Python 2.6 as a separate install, then using virtualenv. Yesterday, I installed Python 2.6 with --enable-shared, so I could compile mod_wsgi - and it worked fine. Today, I had to start from scratch, and re-installed Python 2.6 as a shared library - and it broke, for reasons unknown. I'm hoping someone can tell me why it broke.

Note that I'm not just asking how to fix it, but why it broke. I'm pretty sure one of the answers to fixing it, will be to "set the LD_LIBRARY_PATH variable". I don't want to do that for two reasons. One, I didn't do it yesterday, and everything worked. Two, I have to avoid breaking the Python 2.4 part of CentOS, and if I add that variable to my environment via .bashrc, I'm not sure what, if anything else, might break.

Installing Python 2.6

deleted/created all relevant directories, not just *make clean*
tar -xzvf Python-2.6.6.tgz
./configure --prefix=/foo/python26 --enable-shared
make
make altinstall

Everything seemed to work, there were no obvious errors in the make outputs. Just that Python wouldn't run.

Hiding a library in plain sight

bin/python2.6: error while loading shared libraries: libpython2.6.so.1.0: 
cannot open shared object file: No such file or directory

[/foo/python26/lib]# ls -l
    lrwxrwxrwx  1 root root      19 May 27 15:09 libpython2.6.so -> libpython2.6.so.1.0*
    -r-xr-xr-x  1 root root 5624403 May 27 15:09 libpython2.6.so.1.0*
    drwxr-xr-x 25 root root   20480 May 27 15:开发者_StackOverflow中文版09 python2.6/

[/foo/python26/bin]# ls -l
    -rwxr-xr-x 1 root root 10142 May 27 15:09 python2.6*
    -rwxr-xr-x 1 root root  1433 May 27 15:09 python2.6-config*
    missing file! yesterday there was a 'python' linked to python2.6

[/foo/python26/bin]# ldd python2.6
    libpython2.6.so.1.0 => not found
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00002ababe46c000)

A third reason I don't want to set LD_LIBRARY_PATH is, it doesn't make any sense. The make process created the shared library, and copied it into the right directory. Python knows where it is, the file is under its own lib directory.

So what changed from yesterday, when it worked, to today when it's broken? I installed a few other packages, like django (which I removed) and nginx - I didn't remove nginx, but I don't see how it could have affected anything.

Thanks to Vensky's post on installing Python 2.6, I have what seems like a fix - although I still don't understand why things broke, and this fix seems kludgy. But at least it's working.

Create a file with this line:

#/etc/ld.so.conf.d/python2.6.conf
/foo/python2.6/lib

Then run the ldconfig command, with no arguments.

Checking that it works:

[~]# ldconfig -p | grep python
libpython2.6.so.1.0 (libc6,x86-64) => /foo/python26/lib/libpython2.6.so.1.0
libpython2.6.so (libc6,x86-64) => /foo/python26/lib/libpython2.6.so
libpython2.4.so.1.0 (libc6,x86-64) => /usr/lib64/libpython2.4.so.1.0
libpython2.4.so (libc6,x86-64) => /usr/lib64/libpython2.4.so

[/foo/python26/bin]# ldd python2.6
libpython2.6.so.1.0 => /foo/python26/lib/libpython2.6.so.1.0 (0x00002b351dc1a000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b351dfca000)

Python 2.6 is definitely working, and appears to be linked to the shared library now. And it doesn't look like it should interfere with the system's Python 2.4.