Виконавчий файл Python не знаходить бібліотеку спільного використання libpython

Я встановлюю Python 2.7 на CentOS 5. Я створив і встановив 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

Коли я запускаю ldd на / usr / local / bin / python, я отримую

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, де знайти лібпітон?

Спробуйте наступне:

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в вашому домашньому каталозі (це працює тільки , якщо ви використовуєте оболонку , яка завантажує цей файл при запуску нового екземпляра оболонки). Цей параметр вплине лише на вашого користувача.

2. Додати /usr/local/libдо /etc/ld.so.confі бігти ldconfig. Це звичайно загальносистемне налаштування.

Одягаючи шапку могили ...

Найкращий спосіб я вирішити це - це час компіляції. Оскільки ви все-таки є одним префіксом налаштування, ви також можете чітко сказати виконуваному файлу, де знайти його спільні бібліотеки. На відміну від OpenSSL та інших програмних пакетів, Python не дає вам приємних директив налаштування для обробки альтернативних шляхів до бібліотеки (не всі є кореневими ви знаєте ...) У найпростішому випадку все, що вам потрібно, це:

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

Або якщо ви віддаєте перевагу нелінукс-версії:

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

Прапор " rpath" повідомляє python, що він має бібліотеки часу виконання, необхідні саме для цього шляху. Ви можете скористатися цією ідеєю далі, щоб обробляти залежності, встановлені в іншому місці, ніж стандартні системні місця. Наприклад, у моїх системах, оскільки у мене немає кореневого доступу та мені потрібно зробити майже повністю автономні установки Python, моя лінія конфігурації виглядає так:

./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"

В цьому випадку я компіляція бібліотеки, пітон використання (як ffi, readlineі т.д.) в extlibкаталог в самому дереві каталогів пітона. Таким чином , я можу очорнити пітона - $ {PYTHON_VERSION} каталогу і посадити його в будь-якому місці , і він буде «працювати» ( при умови , що ви не зіткнетеся в libcабо libmконфліктів). Це також допомагає при спробі запуску декількох версій Python в одному і тому ж вікні, оскільки вам не потрібно продовжувати змінювати LD_LIBRARY_PATHабо переживати за те, щоб вибрати неправильну версію бібліотеки Python.

Редагувати: забути згадати, компіляція поскаржиться, якщо ви не встановите PYTHONPATHзмінну середовища на те, що ви використовуєте як свій префікс, і не зможете скласти деякі модулі, наприклад, розширити приклад вище, встановити PYTHONPATHпрефікс, який використовується у вище наприклад з export PYTHONPATH=/apps/python-${PYTHON_VERSION}...

У мене була така ж проблема, і я вирішив її так:

Якщо ви знаєте, де знаходиться лібпітон, я вважаю, що це буде /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ще раз і побачите, чи спрацювало воно.

Я встановив Python 3.5 програмою Колекції програмного забезпечення на CentOS 7 мінімальний. Це все добре спрацювало самостійно, але я побачив помилку спільної бібліотеки, згадану в цьому питанні, коли я спробував запустити простий сценарій 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

Після перезавантаження все добре на оболонці, але іноді мій веб-сервер все ще скаржиться. Є ще один підхід, який завжди працював як для оболонки, так і для сервера, і є більш загальним. Я побачив рішення тут, а потім зрозумів, що насправді згадується і в одній з відповідей тут! У будь-якому випадку, на 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користувачеві апашіти, щоб позбутися помилки дозволу після цього.

Зауважте, що я використовував пошук, щоб знайти каталог для бібліотеки. Ви також можете зробити:

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, як показано вище.

На Солярісі 11

Використовуйте LD_LIBRARY_PATH_64для вирішення символьної посилання на ліфти пітона.

У моєму випадку для python3.6 LD_LIBRARY_PATHне працювало, але LD_LIBRARY_PATH_64було.

Сподіваюся, це допомагає.
З повагою

Це працювало для мене ...

$ sudo apt-get install python2.7-dev

Я встановив за допомогою команди:

./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: не вдається відкрити спільний файл об'єкта: такого файлу чи каталогу немає

Потім я вийшов з кореневого користувача і знову спробував виконати Python, і він успішно працював.

Все, що потрібно - це встановлення файлів libpython [3 або 2] dev.

просто встановіть python-lib. (python27-lib). Він встановить libpython2.7.so1.0. Нам не потрібно нічого вручну встановлювати.