在GNU/Linux上手动构建python 2.7.10，从包中加载旧python2.7.6的.so

Question

我已经成功地从源代码构建并安装了python 2.7.10版本到文件夹/usr/local。然后我执行了/usr/local/bin/python，它显示它的版本是2.7.6。这是不正确的。试图找出什么是错误的，我已经运行了ldd/usr/local/bin/python，并得到以下内容:

    linux-vdso.so.1 =>  (0x00007fffd5fe4000)
    libpython2.7.so.1.0 => /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0 (0x00007f2c006f8000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f2c004da000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2c00115000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f2bffefc000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f2bffcf8000)
    libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f2bffaf5000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f2bff7ef000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f2c00c5c000)

这意味着手动构建的python 2.7.10加载*。python 2.7.6的库，它是由默认的包管理器安装的。你能帮忙找出发生这种情况的原因吗?

配置已通过以下命令完成:

。/configure——prefix=/usr/local——enable-shared

我使用的是Linux Mint 17.2 Rafaela KDE版，它是基于Ubuntu 14.04.3

Answer 1

原因是linux用来选择要加载的共享对象的算法。此过程允许同一库的多个版本在同一系统中共存而不会出现问题。有时候，必须先触碰某些东西，才能迫使它选择另一个选项，就像现在对你来说一样。

我将首先解释算法，然后再解释你的解决方案:

首先linux有一个二进制数据库索引的soname(这是一个名称的动态链接器使用，以选择适当的库版本)，它进入了所谓的soname在库(嵌入在应用程序时，它被链接)，并获得一个文件(通常文件名是/usr/lib/ soname)，数据库是通过搜索目录列表(配置在/etc/ld.so.conf)为所有库，提取他们的soname s，并索引从soname到实际文件构建的。为了快速工作，库有一个指向文件名的符号链接，，这就是为什么你链接到错误的库，链接指向旧版本。

剩下的很简单。您将找到一个库，例如/usr/lib/libfoo.so.1(在本例中名称为libfoo.so.1)，它有两个版本，/usr/lib/libfoo.so.1.3和/usr/lib/libfoo.so.1.4，以及一个符号链接 /usr/lib/libfoo.so.1 -> /usr/lib/libfoo.so.1.3。您必须删除此链接并构建正确的链接。

rm -f /usr/lib/libfoo.so.1
ln -s libfoo.so.1.3 /usr/lib/libfoo.so.1

在那之后，用 重建数据库会很好(我认为这是没有必要的，因为你已经安装了它，但没有伤害)。

/sbin/ldconfig

如果你用-l运行它，它会显示它在数据库中的所有共享库。试试ldconfig(8) .

Answer 2

将/usr/local添加到$LD_LIBRARY_PATH中已解决问题。解决方案的其他变体在这里Python可执行文件找不到libpython共享库