When I try to execute a framework for a university assignment, I get
$ ./Assignment
./Assignment: error while loading shared libraries: libOpenCL.so.1: cannot open shared object file: No such file or directory
I use a computer at university. That means I have no root access. However, if I can say what exactly is the problem the administrators might help me.
- CUDA seems to be installed (
nvidia-smiandnvcc --helpboth work). libOpenCl.soexists on the system
Information about my system
$ echo $LD_LIBRARY_PATH
:/opt/cuda-7.5/lib64:/home/stud/s_thoma/cuda
$ echo $LIBGL_DRIVERS_PATH
:/home/stud/s_thoma/cuda:/opt/cuda-7.5/lib64:/home/stud/s_thoma/cuda
/opt/cuda-7.5/lib64$ ls
libcublas_device.a libcuinj64.so.7.5.18 libnppi.so.7.5.18
libcublas.so libculibos.a libnppi_static.a
libcublas.so.7.5 libcurand.so libnpps.so
libcublas.so.7.5.18 libcurand.so.7.5 libnpps.so.7.5
libcublas_static.a libcurand.so.7.5.18 libnpps.so.7.5.18
libcudadevrt.a libcurand_static.a libnpps_static.a
libcudart.so libcusolver.so libnvblas.so
libcudart.so.7.5 libcusolver.so.7.5 libnvblas.so.7.5
libcudart.so.7.5.18 libcusolver.so.7.5.18 libnvblas.so.7.5.18
libcudart_static.a libcusolver_static.a libnvrtc-builtins.so
libcufft.so libcusparse.so libnvrtc-builtins.so.7.5
libcufft.so.7.5 libcusparse.so.7.5 libnvrtc-builtins.so.7.5.18
libcufft.so.7.5.18 libcusparse.so.7.5.18 libnvrtc.so
libcufft_static.a libcusparse_static.a libnvrtc.so.7.5
libcufftw.so libnppc.so libnvrtc.so.7.5.17
libcufftw.so.7.5 libnppc.so.7.5 libnvToolsExt.so
libcufftw.so.7.5.18 libnppc.so.7.5.18 libnvToolsExt.so.1
libcufftw_static.a libnppc_static.a libnvToolsExt.so.1.0.0
libcuinj64.so libnppi.so libOpenCL.so
libcuinj64.so.7.5 libnppi.so.7.5 stubs
~/cuda$ ls
libOpenCL.so.1
$ uname -a
Linux i08pc71 4.0.4-303.ATIS.aufs4.0.fc22.x86_64 #1 SMP Wed Jun 3 13:02:20 CEST 2015 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/issue
Fedora release 22 (Twenty Two)
Kernel r on an m (l)
asked Dec 22, 2015 at 18:45
Martin ThomaMartin Thoma
2,7325 gold badges33 silver badges45 bronze badges
strace will help you to debug your issue. It will show you where dynamic linker looks for libOpenCL.so.1. Note that you may ended up with a broken symlink inside your ~/cuda directory.
To properly test for this, install or otherwise get an strace binary and then run:
strace -f -v -s150 ./Assignment 2>&1 | fgrep libOpenCL.so.1
answered Dec 22, 2015 at 18:55
3
Дано:
Видеокарта Radeon RX 460 с драйвером amdgpu;
Mesa, у которой OpenCL версии 1.1;
Fedora 26;
До этого в Manjaro просто из AUR ставился соответствующий пакет и всё работало замечательно. До перехода на федору нашел вот этот вот пост. Сделал точно так же, сначала просто стала невидимой видеокарта для clinfo, теперь:
[ozzee@localhost] $ LD_LIBRARY_PATH=/opt/amdgpu-pro/lib64/ clinfo
DRM_IOCTL_I915_GEM_APERTURE failed: Invalid argument
Assuming 131072kB available aperture size.
May lead to reduced performance or incorrect rendering.
get chip id failed: -1 [2]
param: 4, val: 0
Segmentation fault (стек памяти сброшен на диск)
При том, что путь верный. Далее, попробовал поставить просто три пакета, связанных с OpenCL (все пакеты были выкачаны с офсайта амд). Ранее были проблемы с зависимостиями, сейчас они поставились, но эффекта никакого — только меса. Попробовал удалить пакеты месовского OpenCL и ocl-icd от месы же, снесся вайн, и
[ozzee@localhost] $ clinfo
clinfo: error while loading shared libraries: libOpenCL.so.1: cannot open shared object file: No such file or directory
Пока вернул пакеты на место.
Есть ли способ воткнуть проприетарный OpenCL? А то блендер не умеет в 1.1, а мне комнату хочется порендерить…
——————————-
Решилось. Вот инструкция:
Качаем с офсайта AMD драйверы под свою видеокарту для CentOS/RHEL. Далее, открываем пакеты с помощью архиватора и ищем папки lib64 и в них такие файлы:
libamdocl12cl64.so
libamdocl64.so
Их копируем в /usr/lib64, предварительно сделав резервные копии libOpenCL*, так как они будут заменяться как оказалось, libOpenCL* заменять не надо, замена этих библиотек (возможно) приводила к зависанию видеокарты, а amdgpu валил ошибками.
Далее ищем файл amdocl64.icd и кладем его в /etc/OpenCL/vendors, а mesa.icd переименовываем к примеру в mesa.bak (он в этом же каталоге). Теперь clinfo должен показывать что-то вроде этого:
Platform Name AMD Accelerated Parallel Processing
Number of devices 1
Device Name Baffin
Device Vendor Advanced Micro Devices, Inc.
Device Vendor ID 0x1002
Device Version OpenCL 1.2 AMD-APP (2442.7)
Driver Version 2442.7
Device OpenCL C Version OpenCL C 1.2
Device Type GPU
Device Available Yes
Device Profile FULL_PROFILE
Device Board Name (AMD) AMD Radeon (TM) RX 460 Graphics
Работоспособность проверена в блендере.
Новые и опытные пользователи Linux могут сталкиваться с ошибкой error loading shared libraries во время запуска программ, также с ней могут сталкиваться программисты и все желающие компилировать программное обеспечение в своей системе. Эта ошибка в дословном переводе означает что возникла проблема во время загрузки общей библиотеки. О том что такое библиотеки и зачем они нужны вы можете узнать из статьи библиотеки Linux.
В этой же статье мы рассмотрим что значит ошибка error while loading shared libraries более подробно, а главное, как ее решить.
Даже если вы не компилируете свои программы, то вы можете увидеть ошибку error while loading shared libraries: имя_библиотеки: cannot open shared object file: No such file or directory достаточно часто во время установки новых программ не через пакетный менеджер или программ, предназначенных для другого дистрибутива. Как я уже говорил, она возникает потому, что система не может найти библиотеку.
А вот почему ее нельзя найти и загрузить, это уже интересно. Этому может быть несколько причин:
- Библиотека не установлена в системе;
- Библиотека установлена, но неизвестно куда;
- Библиотека установлена правильно, но имеет не ту версию.
При решении проблемы мы будем руководствоваться именно этими причинами и пытаться их решить.
Как исправить ошибку?
1. Библиотека не установлена
Первый вариант, тут все понятно, библиотеки просто нет в системе, поэтому мы и получаем такую ошибку. Верный способ ее решения — просто найти пакет библиотеки с помощью пакетного менеджера и установить ее. Обычно, пакеты с библиотеками называются так же, как и сами библиотеки с префиксом lib.
Например, если нам не хватает библиотеки libfuse2.so, то мы можем найти ее в Ubuntu такой командой:
sudo apt search libfuse2
Затем осталось только установить ее:
sudo apt install libfuse2
Если перед вами стоит задача собрать программу из исходников, то вам понадобится не только установить саму библиотеку, но и заголовочные файлы для нее:
sudo apt install libfuse-dev
И так для любой библиотеки. Но это не всегда помогает.
2. Библиотека находится не в том каталоге
Бывает что библиотека установлена, мы установили ее или она поставлялась вместе с программой, но ошибка как была, так и есть. Причиной этому может быть то, что загрузчик Linux не может найти библиотеку.
Поиск библиотек выполняется по всех папках, которые указаны в конфигурационных файлах /etc/ld.conf.d/. По умолчанию, это такие каталоги, как /usr/lib, /lib, /usr/lib64, /lib64. Если библиотека установлена в другой каталог, то, возможно, это и есть причина проблемы.
Вы можете посмотреть какие библиотеки сейчас доступны загрузчику с помощью команды:
ldconfig -p
Найти, где находится ваша библиотека можно с помощью команды locate. Например, нас интересует библиотека librtfreader.so:
locate librtfreader
Теперь мы знаем, что она находится по адресу /opt/kingsoft/wps-office/office6/. А значит, для работы программы необходимо сделать чтобы загрузчик библиотек ее видел. Для этого можно добавить путь в один из файлов /etc/ld.so.conf.d/ или же в переменную LD_LIBRARY_PATH:
export LD_LIBRARY_PATH=/opt/kingsoft/wps-office/office6/
Опять же, так вы можете поставить с любой библиотекой, которая взывает ошибку. Еще один более простой метод — это просто создать символическую ссылку на нужную библиотеку в правильной папке:
ln -s /opt/kingsoft/wps-office/office6/librtfreader.so /usr/lib/librtfreader.so
3. Неверная версия библиотеки
Эта причина ошибки довольно часто встречается при использовании программ не для вашего дистрибутива. Каждая библиотека имеет дополнительную версию, так называемую ревизию, которая записывается после расширения .so. Например, libav.so.1. Так вот, номер версии меняется всякий раз, когда в библиотеку вносятся какие-либо исправления.
Часто возникает ситуация, когда в одном дистрибутиве программа собирается с зависимостью от библиотеки, например, libc.so.1, а в другом есть только libc.so.2. Отличия в большинстве случаев здесь небольшие и программа могла бы работать на второй версии библиотеки. Поэтому мы можем просто создать символическую ссылку на нее.
Например, библиотеки libusb-1.0.so.1 нет. Но зато есть libusb-1.0.so.0.1, и мы можем ее использовать:
Для этого просто создаем символическую ссылку на библиотеку:
sudo ln -s /usr/lib/libusb-1.0.so.0.1 /usr/lib/libusb-1.0.so.1
В большинстве случаев программа не заметит подмены и будет работать, как и ожидалось. Также для решения этой проблемы можно попытаться найти нужную версию библиотеки в интернете для своей архитектуры и поместить ее в папку /usr/lib/ или /usr/lib64/. Но после этого желательно обновить кэш:
sudo ldconfig
Выводы
В этой статье мы рассмотрели почему возникает ошибка Error while loading shared libraries, а также как ее решить. В большинстве случаев проблема решается довольно просто и вы получите работоспособную программу. Надеюсь, эта информация была полезной для вас.
Статья распространяется под лицензией Creative Commons ShareAlike 4.0 при копировании материала ссылка на источник обязательна .
Sometimes, when you try to install a program or a package from its source code, you might end up getting an error which looks like :
“error while loading shared libraries: cannot open shared object file No such file or directory”
In general, if the package shared library name is lib, the error sometimes shows the following :
“error while loading shared libraries: lib.so.X: cannot open shared object file: No such file or directory “
Where X is a number.
These dynamically generated shared libraries, which are required by executables, are stored under /lib or /usr/lib directories.
The command below can help find out the libraries that are needed for a given executable :
ldd nw
As a quick workaround, you could try to fix the issue by running ldconfig command below :
sudo ldconfig -v
Now at runtime, the system would need to locate the ‘.so’ corresponding library file since the package or the program is linked with the library shared version.
To locate the library, invoke the command below :
sudo find / -name lib_file.so.x
or you could use apt search command. Jot down the path in which the lib_file.so.x is found, path_to_so_file.
Read: How to find the largest files on Linux
To include the folder in which the library is installed, the shell variable LD_LIBRARY_PATH has to be provided.
If LD_LIBRARY_PATH is not defined (run echo $LD_LIBRARY_PATH to find out), you could set it using the command (in the Bash shell) :
LD_LIBRARY_PATH=/usr/local/lib
Now using the path of the .so file that you found above, path_to_so_file, run the commands below :
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:path_to_so_file
export LD_LIBRARY_PATH $ ./your_package
You can find out more about shared libraries here.
If you like the content, we would appreciate your support by buying us a coffee. Thank you so much for your visit and support.
Nikolaus Oosterhof
Nikolaus has a degree in software development. He is passionate about gadgets with a screen, nostalgic for phones, a retired gamer and open source programmer. He likes also to write about macOS and Windows. design web pages and debug long programs!