Python可执行文件找不到libpython共享库

问题:Python可执行文件找不到libpython共享库

我正在CentOS 5上安装Python 2.7。我按照以下步骤构建和安装Python:

./configure --enable-shared --prefix=/usr/local
make
make install

当我尝试运行/ usr / local / bin / python时,出现此错误消息

/usr/local/bin/python: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory

当我在/ usr / local / bin / python上运行ldd时,我得到

ldd /usr/local/bin/python
    libpython2.7.so.1.0 => not found
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00000030e9a00000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00000030e9200000)
    libutil.so.1 => /lib64/libutil.so.1 (0x00000030fa200000)
    libm.so.6 => /lib64/libm.so.6 (0x00000030e9600000)
    libc.so.6 => /lib64/libc.so.6 (0x00000030e8e00000)
    /lib64/ld-linux-x86-64.so.2 (0x00000030e8a00000)

如何告诉Python在哪里可以找到libpython?

I am installing Python 2.7 on CentOS 5. I built and installed Python as follows

./configure --enable-shared --prefix=/usr/local
make
make install

When I try to run /usr/local/bin/python, I get this error message

/usr/local/bin/python: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory

When I run ldd on /usr/local/bin/python, I get

ldd /usr/local/bin/python
    libpython2.7.so.1.0 => not found
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00000030e9a00000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00000030e9200000)
    libutil.so.1 => /lib64/libutil.so.1 (0x00000030fa200000)
    libm.so.6 => /lib64/libm.so.6 (0x00000030e9600000)
    libc.so.6 => /lib64/libc.so.6 (0x00000030e8e00000)
    /lib64/ld-linux-x86-64.so.2 (0x00000030e8a00000)

How do I tell Python where to find libpython?


回答 0

尝试以下方法:

LD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/python

如果不在中/usr/local/lib,请替换为已安装的文件夹。libpython2.7.so.1.0/usr/local/lib

如果这可行并且您想使更改永久生效,则有两个选择:

  1. 添加export LD_LIBRARY_PATH=/usr/local/lib到您.profile的主目录中(仅当您使用启动新Shell实例时加载此文件的Shell时,此方法才有效)。此设置仅会影响您的用户。

  2. 添加/usr/local/lib/etc/ld.so.conf和运行ldconfig。当然,这是系统范围的设置。

Try the following:

LD_LIBRARY_PATH=/usr/local/lib /usr/local/bin/python

Replace /usr/local/lib with the folder where you have installed libpython2.7.so.1.0 if it is not in /usr/local/lib.

If this works and you want to make the changes permanent, you have two options:

  1. Add export LD_LIBRARY_PATH=/usr/local/lib to your .profile in your home directory (this works only if you are using a shell which loads this file when a new shell instance is started). This setting will affect your user only.

  2. Add /usr/local/lib to /etc/ld.so.conf and run ldconfig. This is a system-wide setting of course.


回答 1

戴上我的掘墓者帽子…

我发现解决此问题的最佳方法是在编译时。由于您是一个设置前缀,因此无论如何最好还是明确告诉可执行文件在哪里可以找到其共享库。与OpenSSL和其他软件包不同,Python并没有为您提供出色的configure指令来处理备用库路径(并不是每个人都是您所知道的root。)在最简单的情况下,您需要做的是:

./configure --enable-shared \
            --prefix=/usr/local \
            LDFLAGS="-Wl,--rpath=/usr/local/lib"

或者,如果您更喜欢非Linux版本:

./configure --enable-shared \
            --prefix=/usr/local \
            LDFLAGS="-R/usr/local/lib"

rpath”标志告诉python它具有在特定路径中需要的运行时库。您可以进一步利用此想法来处理安装到标准系统位置以外的位置的依赖项。例如,在我的系统上,由于我没有超级用户访问权限,并且需要进行几乎完全独立的Python安装,因此我的configure行如下所示:

./configure --enable-shared \
            --with-system-ffi \
            --with-system-expat \
            --enable-unicode=ucs4 \
            --prefix=/apps/python-${PYTHON_VERSION} \
            LDFLAGS="-L/apps/python-${PYTHON_VERSION}/extlib/lib -Wl,--rpath=/apps/python-${PYTHON_VERSION}/lib -Wl,--rpath=/apps/python-${PYTHON_VERSION}/extlib/lib" \
            CPPFLAGS="-I/apps/python-${PYTHON_VERSION}/extlib/include"

在这种情况下,我在编译库,Python使用(如ffireadline等)到extlibPython目录树本身的目录。这样,我可以将python-$ {PYTHON_VERSION}目录焦油放置在任何地方,它将“起作用”(前提是您不遇到libc任何libm冲突)。当您尝试在同一盒子上运行多个版本的Python时,这也很有帮助,因为您无需不断更改LD_LIBRARY_PATH或担心选择错误版本的Python库。

编辑:忘了提,如果你不设定编译会抱怨PYTHONPATH环境变量,您所使用的作为前缀,并且无法编译某些模块,例如,延长上面的例子中,设置PYTHONPATH在上使用的前缀以export PYTHONPATH=/apps/python-${PYTHON_VERSION}… 为例

Putting on my gravedigger hat…

The best way I’ve found to address this is at compile time. Since you’re the one setting prefix anyway might as well tell the executable explicitly where to find its shared libraries. Unlike OpenSSL and other software packages, Python doesn’t give you nice configure directives to handle alternate library paths (not everyone is root you know…) In the simplest case all you need is the following:

./configure --enable-shared \
            --prefix=/usr/local \
            LDFLAGS="-Wl,--rpath=/usr/local/lib"

Or if you prefer the non-linux version:

./configure --enable-shared \
            --prefix=/usr/local \
            LDFLAGS="-R/usr/local/lib"

The “rpath” flag tells python it has runtime libraries it needs in that particular path. You can take this idea further to handle dependencies installed to a different location than the standard system locations. For example, on my systems since I don’t have root access and need to make almost completely self-contained Python installs, my configure line looks like this:

./configure --enable-shared \
            --with-system-ffi \
            --with-system-expat \
            --enable-unicode=ucs4 \
            --prefix=/apps/python-${PYTHON_VERSION} \
            LDFLAGS="-L/apps/python-${PYTHON_VERSION}/extlib/lib -Wl,--rpath=/apps/python-${PYTHON_VERSION}/lib -Wl,--rpath=/apps/python-${PYTHON_VERSION}/extlib/lib" \
            CPPFLAGS="-I/apps/python-${PYTHON_VERSION}/extlib/include"

In this case I am compiling the libraries that python uses (like ffi, readline, etc) into an extlib directory within the python directory tree itself. This way I can tar the python-${PYTHON_VERSION} directory and land it anywhere and it will “work” (provided you don’t run into libc or libm conflicts). This also helps when trying to run multiple versions of Python on the same box, as you don’t need to keep changing your LD_LIBRARY_PATH or worry about picking up the wrong version of the Python library.

Edit: Forgot to mention, the compile will complain if you don’t set the PYTHONPATH environment variable to what you use as your prefix and fail to compile some modules, e.g., to extend the above example, set the PYTHONPATH to the prefix used in the above example with export PYTHONPATH=/apps/python-${PYTHON_VERSION}


回答 2

我遇到了同样的问题,并以这种方式解决了这个问题:

如果您知道libpython所在的位置,那么我想应该是/usr/local/lib/libpython2.7.so.1.0这样,您可以创建指向它的符号链接:

sudo ln -s /usr/local/lib/libpython2.7.so.1.0 /usr/lib/libpython2.7.so.1.0

然后尝试ldd再次运行,看看是否有效。

I had the same problem and I solved it this way:

If you know where libpython resides at, I supposed it would be /usr/local/lib/libpython2.7.so.1.0 in your case, you can just create a symbolic link to it:

sudo ln -s /usr/local/lib/libpython2.7.so.1.0 /usr/lib/libpython2.7.so.1.0

Then try running ldd again and see if it worked.


回答 3

我在CentOS 7最低版本上按软件集合安装了Python 3.5 。一切都很好,但是当我尝试运行一个简单的CGI脚本时,我看到了这个问题中提到的共享库错误:

tail /var/log/httpd/error_log
AH01215: /opt/rh/rh-python35/root/usr/bin/python: error while loading shared libraries: libpython3.5m.so.rh-python35-1.0: cannot open shared object file: No such file or directory

我想要一个适用于所有用户的系统范围内的永久解决方案,从而避免在.profile或.bashrc文件中添加导出语句。有一个基于Red Hat解决方案页面的单行解决方案。感谢您指出的评论:

echo 'source scl_source enable rh-python35' | sudo tee --append /etc/profile.d/python35.sh

重新启动后,在Shell上一切正常,但是有时我的Web服务器仍然抱怨。还有另一种方法始终适用于外壳程序和服务器,并且更为通用。我在这里看到了解决方案,然后意识到它实际上也在这里的答案之一中提到了!无论如何,在CentOS 7上,这些步骤是:

 vim /etc/ld.so.conf

我机器上的哪个刚刚有:

include ld.so.conf.d/*.conf

所以我创建了一个新文件:

vim /etc/ld.so.conf.d/rh-python35.conf

并添加:

/opt/rh/rh-python35/root/usr/lib64/

并手动重建缓存:

sudo ldconfig

就是这样,脚本可以正常工作!

这是一个临时解决方案,不适用于重新启动:

sudo ldconfig /opt/rh/rh-python35/root/usr/lib64/ -v

-v(详细)选项只是为了查看发生了什么。我看到它确实做到了:/ opt / rh / rh-python35 / root / usr / lib64:libpython3.so.rh-python35-> libpython3.so.rh-python35 libpython3.5m.so.rh-python35-1.0-> libpython3.5m.so.rh-python35-1.0

这个特殊的错误消失了。顺便说一句,chown在那之后,我不得不让用户去摆脱权限错误。

请注意,我使用find来查找库的目录。您也可以这样做:

sudo yum install mlocate
sudo updatedb
locate libpython3.5m.so.rh-python35-1.0

我的VM上哪个返回:

/opt/rh/rh-python35/root/usr/lib64/libpython3.5m.so.rh-python35-1.0

如上所示,这是我需要给ldconfig的路径。

I installed Python 3.5 by Software Collections on CentOS 7 minimal. It all worked fine on its own, but I saw the shared library error mentioned in this question when I tried running a simple CGI script:

tail /var/log/httpd/error_log
AH01215: /opt/rh/rh-python35/root/usr/bin/python: error while loading shared libraries: libpython3.5m.so.rh-python35-1.0: cannot open shared object file: No such file or directory

I wanted a systemwide permanent solution that works for all users, so that excluded adding export statements to .profile or .bashrc files. There is a one-line solution, based on the Red Hat solutions page. Thanks for the comment that points it out:

echo 'source scl_source enable rh-python35' | sudo tee --append /etc/profile.d/python35.sh

After a restart, it’s all good on the shell, but sometimes my web server still complains. There’s another approach that always worked for both the shell and the server, and is more generic. I saw the solution here and then realized it’s actually mentioned in one of the answers here as well! Anyway, on CentOS 7, these are the steps:

 vim /etc/ld.so.conf

Which on my machine just had:

include ld.so.conf.d/*.conf

So I created a new file:

vim /etc/ld.so.conf.d/rh-python35.conf

And added:

/opt/rh/rh-python35/root/usr/lib64/

And to manually rebuild the cache:

sudo ldconfig

That’s it, scripts work fine!

This was a temporary solution, which didn’t work across reboots:

sudo ldconfig /opt/rh/rh-python35/root/usr/lib64/ -v

The -v (verbose) option was just to see what was going on. I saw that it did: /opt/rh/rh-python35/root/usr/lib64: libpython3.so.rh-python35 -> libpython3.so.rh-python35 libpython3.5m.so.rh-python35-1.0 -> libpython3.5m.so.rh-python35-1.0

This particular error went away. Incidentally, I had to chown the user to apache to get rid of a permission error after that.

Note that I used find to locate the directory for the library. You could also do:

sudo yum install mlocate
sudo updatedb
locate libpython3.5m.so.rh-python35-1.0

Which on my VM returns:

/opt/rh/rh-python35/root/usr/lib64/libpython3.5m.so.rh-python35-1.0

Which is the path I need to give to ldconfig, as shown above.


回答 4

在Solaris 11上

用于LD_LIBRARY_PATH_64将符号链接解析为python库。

就我而言,对于python3.6 LD_LIBRARY_PATH无效,但是有效LD_LIBRARY_PATH_64

希望这可以帮助。
问候

On Solaris 11

Use LD_LIBRARY_PATH_64 to resolve symlink to python libs.

In my case for python3.6 LD_LIBRARY_PATH didn’t work but LD_LIBRARY_PATH_64 did.

Hope this helps.
Regards


回答 5

这对我有用…

$ sudo apt-get install python2.7-dev

This worked for me…

$ sudo apt-get install python2.7-dev

回答 6

我使用以下命令安装:

./configure --prefix=/usr       \
            --enable-shared     \
            --with-system-expat \
            --with-system-ffi   \
            --enable-unicode=ucs4 &&

make

现在,以root用户身份:

make install &&
chmod -v 755 /usr/lib/libpython2.7.so.1.0

然后我尝试执行python并得到错误:

/ usr / local / bin / python:加载共享库时出错:libpython2.7.so.1.0:无法打开共享库文件:没有这样的文件或目录

然后,我从root用户注销,再次尝试执行Python,它成功运行。

I installed using the command:

./configure --prefix=/usr       \
            --enable-shared     \
            --with-system-expat \
            --with-system-ffi   \
            --enable-unicode=ucs4 &&

make

Now, as the root user:

make install &&
chmod -v 755 /usr/lib/libpython2.7.so.1.0

Then I tried to execute python and got the error:

/usr/local/bin/python: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory

Then, I logged out from root user and again tried to execute the Python and it worked successfully.


回答 7

它只需要安装libpython [3或2] dev文件即可。

All it needs is the installation of libpython [3 or 2] dev files installation.


回答 8

只需安装python-lib。(python27-lib)。它将安装libpython2.7.so1.0。我们不需要手动设置任何内容。

just install python-lib. (python27-lib). It will install libpython2.7.so1.0. We don’t require to manually set anything.