Solutions for Python Executable Unable to Find libpython Shared Library

Problem Analysis

When compiling and installing Python 2.7 with the --enable-shared option on CentOS 5, running /usr/local/bin/python results in the error: libpython2.7.so.1.0: cannot open shared object file: No such file or directory. Using the ldd command to examine dependencies reveals that libpython2.7.so.1.0 is listed as not found.

Root Cause

This issue stems from the dynamic linker's inability to locate the Python shared library. In Linux systems, executables require shared libraries to be loaded at runtime. The dynamic linker searches for libraries in a specific order, including:

• RPATH or RUNPATH specified during compilation
• LD_LIBRARY_PATH environment variable
• Entries in /etc/ld.so.cache
• Default system library paths (e.g., /lib, /usr/lib)

When Python is compiled with --enable-shared, the resulting executable depends on libpython2.7.so.1.0, which is located in /usr/local/lib. However, this directory is not included in the system's default library search paths.

Solution 1: Using LD_LIBRARY_PATH Environment Variable

The most straightforward solution is to set the LD_LIBRARY_PATH environment variable to temporarily specify the shared library search path:

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

If libpython2.7.so.1.0 is not in /usr/local/lib, replace the path with the actual directory containing the library file.

Permanent Solutions

If the temporary solution works, consider the following permanent configuration methods:

User-Level Configuration

Add the following line to the .profile file in the user's home directory:

export LD_LIBRARY_PATH=/usr/local/lib

This setting applies only to the current user and requires re-login or executing source ~/.profile to take effect.

System-Level Configuration

To affect all users, modify the system-wide library configuration:

1. Edit the /etc/ld.so.conf file and add a line: /usr/local/lib
2. Run the ldconfig command to update the dynamic linker cache

This method requires root privileges but will be effective for all users and processes once configured.

Preventive Measure: Specifying Runtime Library Path During Compilation

To avoid similar issues in the future, specify the runtime library search path during Python compilation using the LDFLAGS parameter:

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

Or for non-Linux systems:

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

The --rpath option embeds the runtime library search path into the executable, allowing Python to find the required shared libraries even without setting LD_LIBRARY_PATH.

In-Depth Understanding

In more complex deployment scenarios, it may be necessary to create completely self-contained Python installations. For example:

./configure --enable-shared --prefix=/apps/python-2.7 LDFLAGS="-Wl,--rpath=/apps/python-2.7/lib"

This approach is particularly suitable for deploying multiple Python versions in environments without root access, or when needing to package and移植 Python environments to other systems.

Conclusion

The issue of Python shared library not being found is essentially a dynamic linking library path configuration problem. By appropriately using the LD_LIBRARY_PATH environment variable, system library configuration, or specifying runtime paths during compilation, this problem can be effectively resolved. The choice of solution depends on specific deployment requirements and environmental constraints.