Libpython2.7.so.1.0: невозможно открыть файл общих объектов: нет такого файла или каталога
Я пытаюсь запустить python script с терминала, но получаю следующее сообщение об ошибке:
ImportError: libpython2.7.so.1.0: cannot open shared object file: No such file or directory
если я запускаю print sys.version, я получаю:
>>> import sys
>>> print sys.version
2.7.3 (default, Feb 26 2013, 16:27:39)
[GCC 4.4.6 20120305 (Red Hat 4.4.6-4)]
и если я запустил ldd/usr/local/bin/python
>> ldd /usr/local/bin/python
linux-vdso.so.1 => (0x00007fff219ff000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003300c00000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003300800000)
libutil.so.1 => /lib64/libutil.so.1 (0x0000003310e00000)
libm.so.6 => /lib64/libm.so.6 (0x0000003300000000)
libc.so.6 => /lib64/libc.so.6 (0x0000003300400000)
/lib64/ld-linux-x86-64.so.2 (0x00000032ffc00000)
Я не понимаю, какой у меня python? почему запуск этого python script с терминала не выполняется?
Я попытался запустить
export LD_LIBRARY_PATH=/usr/local/lib/python2.7/
без везения...
BTW - мне удалось отладить этот script в eclipse с помощью подключаемого модуля python, и когда я смотрю на конфигурацию отладки, я вижу, что PYTHONPATH установлен для:
/..../eclipse/plugins/org.python.pydev_3.1.0.201312121632/pysrc/pydev_sitecustomize:/..../workspace/style_checker/src:/usr/local/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg:/usr/local/lib/python2.7/site-packages/pip-1.2.1-py2.7.egg:/usr/local/lib/python2.7:/usr/local/lib/python2.7/plat-linux2:/usr/local/lib/python2.7/lib-tk:/usr/local/lib/python2.7/lib-dynload:/usr/local/lib/python2.7/site-packages
поэтому eclipse управляет каким-то образом, чтобы найти это python2.7 libs... так как я могу это сделать с помощью eclipse и из командной строки? Что я делаю не так? используя CentOS6.
Ответы
Ответ 1
Попробуйте найти файл libpython2.7.so.1.0
:
locate libpython2.7.so.1.0
В моем случае это выложено:
/opt/rh/python27/root/usr/lib64/libpython2.7.so.1.0
Затем вставьте строку /opt/rh/python27/root/usr/lib64
в файл /etc/ld.so.conf
И запустите ldconfig
. Это решило мою проблему. Удачи!
Ответ 2
По некоторым причинам эти два отлично спомогли мне:
apt-get install libpython2.7
sudo apt-get install libatlas3-base
Я нашел их здесь и здесь
Ответ 3
Возможно, вы могли бы попробовать ответить на fooobar.com/questions/65093/....
Автор этого вопроса также заявил, что подход LD_LIBRARY_PATH не работает для него, но добавляет путь библиотеки к /etc/ld.so.conf
и работает ldconfig
.
Ответ 4
Это не та тема, которой я увлекаюсь, но я понимаю, что для машин с Linux, особенно (где вы компилируете двоичные файлы Python), каталоги совместно используемых библиотек должны быть указаны на этапе компиляции.
Например, следуя связанному примеру, я гарантирую, что libpython2.7.so.1.0
включен в дополнение к другим библиотекам:
./configure --enable-shared \
--prefix=/directory/for/Python-2.7.15 \
LDFLAGS="-Wl,--rpath=/usr/local/lib -Wl,--rpath=/directory/for/Python-2.7.15"
Обратите внимание, что я также устанавливаю python в фиксированную директорию по своему выбору с помощью опции --prefix
. Это может быть не нужно для вас, но я сделал это, чтобы предоставить решение для общего случая, когда ваша установка на python может находиться где угодно.
С вышеупомянутым решением мне никогда не придется экспортировать LD_LIBRARY_PATH
или связываться с ldconfig
Ответ 5
Я решил это с помощью "export LD_LIBRARY_PATH =" $ {WORK_PATH}/venv/lib ".
Ответ 6
Добавление к правильному ответу:
Несколько вопросов о том, как следующее:
Затем вставьте строку /opt/rh/python27/root/usr/lib64 в файл /etc/ld.so.conf
Правильный способ сделать это - добавить новый файл в /etc/ld.so.conf.d/и добавить строку выше в этом файле.
Ответ 7
У меня была похожая проблема при выполнении 32-битного двоичного файла GDB на 64-битном Linux:
arm-eabi-gdb: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory
и я решил это, установив libpython2.7:i386
(обратите внимание: суффикс i386)