Linux error while loading shared libraries no such file or directory

Ошибка error while loading shared libraries

Новые и опытные пользователи Linux могут сталкиваться с ошибкой error loading shared libraries во время запуска программ, также с ней могут сталкиваться программисты и все желающие компилировать программное обеспечение в своей системе. Эта ошибка в дословном переводе означает что возникла проблема во время загрузки общей библиотеки. О том что такое библиотеки и зачем они нужны вы можете узнать из статьи библиотеки Linux.

В этой же статье мы рассмотрим что значит ошибка error while loading shared libraries более подробно, а главное, как ее решить.

Что означает 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. Если библиотека установлена в другой каталог, то, возможно, это и есть причина проблемы.

Вы можете посмотреть какие библиотеки сейчас доступны загрузчику с помощью команды:

Найти, где находится ваша библиотека можно с помощью команды locate. Например, нас интересует библиотека librtfreader.so:

Теперь мы знаем, что она находится по адресу /opt/kingsoft/wps-office/office6/. А значит, для работы программы необходимо сделать чтобы загрузчик библиотек ее видел. Для этого можно добавить путь в один из файлов /etc/ld.so.conf.d/ или же в переменную LD_LIBRARY_PATH:

Опять же, так вы можете поставить с любой библиотекой, которая взывает ошибку. Еще один более простой метод — это просто создать символическую ссылку на нужную библиотеку в правильной папке:

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/. Но после этого желательно обновить кэш:

Выводы

В этой статье мы рассмотрели почему возникает ошибка Error while loading shared libraries, а также как ее решить. В большинстве случаев проблема решается довольно просто и вы получите работоспособную программу. Надеюсь, эта информация была полезной для вас.

Источник

Error loading shared libraries

I’m running eclipse on Ubuntu using a g++ compiler and I’m trying to run a sample program that utilizes xerces.

The build produced no errors however, when i attempted to run the program, I would receive this error:

error while loading shared libraries: libxerces-c-3.1.so: cannot open shared object file: No such file or directory

libxerces-c-3.1.so is in the directory /opt/lib which I have included as a library in eclipse. The file is there when I checked the folder. When I perform an echo $LD_LIBRARY_PATH , /opt/lib is also listed.

Any ideas into where the problem lies? Thanks.

An ldd libxerces-c-3.1.so command yields the following output:

5 Answers 5

Try running ldconfig as root to see if it solves the problem.

Run ldd libxerces-c-3.1.so and examine the output to see if all dependencies can be found.

I copied all the library files from /opt/lib into /usr/lib and the program works now. Thanks for the response.

Try installing the library libxerces-c3.1 as. Use the command mentioned below to install the library.

This worked like a charm for me.

There are many ways to do this, most already mentioned here. BUT you want to avoid accidentally copying your library files into/over those of the system. This is easily done since people have little imagination in making original unique names for their libraries.

So there are a couple of things to think about:

• Do you need these files to be a permanent part of your system?
• Do you only need to install for testing and frequent updates?
• Do you only need them for running that particular command once or twice?
• Where are your native libraries located?

To find your various library locations on your system (apart from using find), look here:

On Linux there are some standard places:

There are many others, but you should most likely stay with /usr/local/lib . Next you need to tell your system where to find these libraries. The cool system dude (who knows what he is doing) way to do this is using ldconfig , however, you may do stuff you regret, if you make a mistake here. The safest way to use that command is by using the flags -v -n to make the command verbose and to specify what library directory you need to add.

Done. But if you only wanna test something, then rather use your LD_LIBRARY_PATH directly from command line, like this:

Alternatively, add the following to your .bashrc script.

Now you can run your dynamically linked command.

Источник

openssl: error while loading shared libraries: libssl.so.3

it doesn’t matter what I type in combination with ‘openssl’, I always get the following error message:

I have no idea how to fix that issue after reading many questions asked in this and in other forums.

6 Answers 6

I had the same issue after installing Openssl 3.0. I resolved the issue by copying the files libcrypto.so.3 , libcrypto.a and libssl.so.3 from /usr/local/lib to /usr/lib . After copying these files, you need to create some symbolic links.

Now rebuild the ldconfig cache:

I solved it that time only by creating a symlink and rebuilding the ldconfig cache.

I compiled openssl from github: https://github.com/openssl/openssl. Examining the Makefile generated (by ./config ) the default install directory is /usr/local/lib64 .

However, on RHEL, this directory is not in the load library path. The following worked for me on RHEL 7.9:

In my case it was related to Python 3.8 install on SLES 12.1. Pip install failed due to OpenSSL error.

Then I cloned the openssl repository and built it from source.

git clone https://github.com/openssl/openssl.git

./Configure make make install

Finally ldconfig is important and needed.

Then openssl version -a should show response without error. At least openssl 1.1 is needed to build Python 3.5+.

After this exercise the Python 3.8.5 build from the source was successful.

Источник

./a.out: error while loading shared libraries: libgsl.so.23: cannot open shared object file: No such file or directory

After installing GNU Scientific Library (GSL) from source code, I write a program to test if the library work.

There is no problem in Compiling and linking procedure. No such file or directory but there is such directory.

4 Answers 4

(Static Library) When compiling write, for example:

gcc -static -I $HOME/local/include -L $HOME/local/lib example.c -lgsl -lgslcblas -lm

(Dynamic Library) When compiling write, for example:

gcc -I $HOME/local/include -L $HOME/local/lib example.c -lgsl -lgslcblas -lm

and to execute it:

Generally you will want to build GNU Software by typing:

./configure [optional necessary cmd line arguments]

You’ve done the first two lines so just do the check and install — then ./a.out should run.

/gsl/lib/ and export LD_LIBRARY_PATH . Then the library work.

I may be a bit late for the question, but I hope this answer can help someone else who’s suffering the same problem.

That’s probably because your gcc don’t know where the shared library is. Actually, you have to explicitly tell your compiler the location of the shared library that is used by your program. The solutions being: Plan A(temporary): In bash, you need

supposing your gsl is installed in the default directory. Plan B(permanent): edit /etc/ld.so.conf (you need sudo this). Put your location at the end of the file:

In vim, type o and then /usr/local/lib. Then type esc and type :wq .

Now recompile your file and it will work. If not, you can run ldd a.out to see if the libraries are linked.

I know that there is little late, but I would like to complement the answer. First, make sure that the local installation that you do is correct by following the steps in https://coral.ise.lehigh.edu/jild13/2016/07/11/hello/. Then, you can compile all in one line as follows:

Also, for this to work properly you need to include the library path in the

/.bashrc as follows:

So, explaining a little: -Wall is for the warning as is widely known. The -I leads to the .h files, which have defined functions and variables needed, and the -L option is for the compiler to be able to know where are the shared libraries. Finally, the -lm and so on options are for the compiler to know to which libraries it must link the output. The fact that the path must be in the .bashrc comes from the fact that the libraries are used dynamically, and so at the run time it must be able to find that path, which is loaded thanks to the bashrc wh.

Источник

error while loading shared libraries: libtinfo.so.5 #1012

Comments

zimurgh commented Sep 19, 2015

So, today a system update of my Arch Linux box ended in tears as stack is now giving me this error whenever I try to build anything.

But I have libtinfo.so.5.

I’ve been able to reproduce this on two separate systems today, both running Arch Linux.

The text was updated successfully, but these errors were encountered:

radix commented Sep 19, 2015

You may have the a symlink libtinfo.so , but it doesn’t appear to be pointing to an existing file (your ls . |grep libtinfo command would have shown the destination file as another line if it had existed).

I don’t have any idea why your libtinfo.so.5 disappeared, though.

zimurgh commented Sep 19, 2015

Found this issue, but I’ve already installed the package the solution involves. It doesn’t seem to work. It’s also flagged out of date.

zimurgh commented Sep 19, 2015

The PKGBUILD provided by the package (right now) is broken. The maintainer has been provided a working PKGBUILD but just hasn’t updated the package yet for some reason. I used the linked PKGBUILD to manually build from source and it worked. I also switched off of haskell-stack-git to haskell-stack , but I doubt that makes a difference for this issue.

arianvp commented Sep 19, 2015

Thanks. I was having a similar issue

jgoux commented Oct 5, 2015

Hello, I had an issue with libtinfo.so as well when doing stack install ghc-mod in my project.
The installation failed because it didn’t find libtinfo.so on my system (ubuntu)
I resolved the issue by manually creating the symlink which didn’t exist :
locate libtinfo.so
sudo ln -s /path/to/libtinfo.so.5 /path/to/libtinfo.so 👍

istathar commented Jul 12, 2016

Hit this upgrading from Fedora 23 to Fedora 24. Fix at as per @emmanueltouzery ‘s suggestion at #2300 (comment) to install ncurses-compat-libs (on Fedora) worked.

pfaaj commented Nov 10, 2016 •

Hit at the same problem while trying to run Cling on Fedora 24. Fixed it by installing ncurses-compat-libs on Fedora 24 just as suggested by @emmanueltouzery / @afcowie.

jairoandre commented Mar 10, 2017

For ArchLinux users:

I had this problem on my VM and I solved by installing the libtinfo package from AUR and then creating a symbolic link to /usr/lib/libtinfo.so:

sudo ln -s /usr/lib/libtinfo.so /usr/lib/libtinfo.so.5

jsc-paneda commented Apr 4, 2017

For ArchLinux users:
Installing ncurses5-compat-libs from the aur is another solution.

magusz commented Nov 2, 2017

Download source from https://ftp.gnu.org/gnu/ncurses/
./configure —prefix= —with-termlib —with-shared
make
make install

it-is-wednesday commented Jan 31, 2018

Solved it for me on Void Linux, GHC 8.2.2 64

DougBeney commented Feb 27, 2018

Recently noticed this issue popping up out of nowhere. My solution was to create a symbolic link between libtinfo.so.6 as libtinfo.so.5. Hope this helps someone else.

walkie commented Mar 6, 2018

Ran into this issue on Fedora 27. Following @DougBeney’s lead, I was able to workaround it by creating this symlink:

BobbyBabes commented May 7, 2018 •

On Arch Linux everything is already installed with the core packages.
Because core package ncurses provides everything you require : https://www.archlinux.org/packages/core/x86_64/ncurses/

Just create a symlink to libncursesw.so.6 with : sudo ln -sf /usr/lib/libncursesw.so.6 /usr/lib/libtinfo.so.5 .
No need to install anything from the AUR.

EDIT: When you expand the Package Contents link on the ncurses package page, you will notice usr/lib/libtinfo.so.6 , which also is a symlink to /usr/lib/libncursesw.so.6 .

nandda commented Mar 12, 2019

even, i created symlink, then also i got the same error.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник