Error while loading shared libraries nuke83 so - Исправление ошибок и поиск оптимальных решений проблем

Содержание

Ошибка error while loading shared libraries
Что означает error while loading shared libraries?
Как исправить ошибку?
1. Библиотека не установлена
2. Библиотека находится не в том каталоге
3. Неверная версия библиотеки
Выводы
Ошибка error while loading shared libraries в Linux
How To Fix “pacman: error while loading shared libraries” Error In Arch Linux
Fix «pacman: error while loading shared libraries» Error In Arch Linux

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

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

Найти, где находится ваша библиотека можно с помощью команды 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, а также как ее решить. В большинстве случаев проблема решается довольно просто и вы получите работоспособную программу. Надеюсь, эта информация была полезной для вас.

Источник

Многие пользователи Linux рано или поздно сталкиваются с ошибкой error while loading shared libraries. Как правило, при установке программ вручную. Сегодня поговорим об исправлении данной ошибки. Для примера возьмём старый ноутбук с Ubuntu 14.04 LTS, поддержка которой недавно закончилась, а значит что-то приходится доустанавливать вручную.

Ошибка error while loading shared libraries означает, что программа, которую пользователь пытается запустить, не смогла найти необходимую для своего запуска библиотеку. Такое часто случается, если программа устанавливалась не из репозиториев, а вручную. Например, на скриншоте ниже мы видим, что свежая версия Mozilla Firefox требует для своей работы библиотеку libatomic.so.1, но не может её обнаружить.

При этом, кстати, совершенно не обязательно, что данная библиотека отсутствует в системе. Поэтому сперва выполним поиск библиотеки (подробнее о locate в статье по этой ссылке):

Естественно, в Вашем случае библиотека может называться иначе. Смотрите, что упоминается в тексте ошибки.

Если команда ничего не выдаст, это значит, что библиотеки в системе нет (а вот если библиотека найдена, тогда об этом ниже).

Поищем библиотеку в репозиториях:

В результате мы получим перечень пакетов, которые в названии содержат libatomic:

В моем случае речь идёт о стареньком ноутбуке с 32-битной системой, поэтому мой выбор пал на libatomic1. Если Вы собираете программу из исходников, то будет полезным поставить не только библиотеку, но и заголовочные файлы с приставкой -dev. Сама установка проста:

В результате — актуальная версия Firefox в уже не поддерживаемой разработчиками Ubuntu (подробнее об установке новых версий Firefox в старых релизах Ubuntu в статье по ссылке).

Кстати, иногда команда locate может не выдать Вам информацию о библиотеке, так как, на самом деле она не осуществляет поиск файлов или каталогов. Но это отдельный разговор. Посмотреть, установлена ли библиотека в системе, можно и при поиске пакетов в репозитории. Как видите, наш пакет libatomic1 теперь помечен как установленный.

Теперь о том, что делать, если библиотека есть в системе, но ошибка error while loading shared libraries всё равно появляется. Очень часто причиной этого является то, что загрузчик ОС не может найти библиотеку. По умолчанию поиск производится в каталогах: /usr/lib, /lib, /usr/lib64, /lib64. Не исключено, что библиотека просто лежит за пределами этих каталогов.

Вариантов тут несколько: переместить или скопировать библиотеку, ну или же указать загрузчику, где её искать. Последний способ более корректный, так как при нём Вы точно ничего не напортачите в системе.

Можно зайти в папку /etc/ld.so.conf.d/, открыть там любой конфигурационный файл и просто прописать местонахождение нужной библиотеки.

А можно сделать символьную (символическую) ссылку:

ln -s [путь_к_библиотеке/имя_библиотеки] /usr/lib/[имя_библиотеки]

Есть ещё одна причина ошибки while loading shared libraries даже когда нужна библиотека имеется в операционной системе. Библиотека может быть не той версии.

Версия библиотеки (или ещё её называют ревизией) пишется после расширения .so. В нашем примере нам требовалась библиотека libatomic.so.1, т.е. libatomic первой версии.

В разных дистрибутивах используются разные версии библиотек, а программы собираются под дистрибутив (и, как следствие, библиотеку конкретной версии). На практике же различия между версиями библиотек чаще всего минимальны. Поэтому для начала можно выдать библиотеку одной версии за библиотеку другой версии. В этом нам опять поможет символьная ссылка:

ln -s [путь_к_библиотеке/настоящее_имя_библиотеки] [путь_к_библиотеке/имя_библиотеки_с_нужной_версией]

Если этот способ не помог, то выход один — искать библиотеку нужной версии.

И последнее: после манипуляций с библиотеками желательно обновить кэш командой

Вот, пожалуй, и всё, что нужно знать про ошибку error while loading shared libraries.

Источник

For the past few days, I have been extensively testing PIP and Pipenv tools in my Arch Linux system. While testing these tools, I had to reinstall and downgrade Python2.x, Python 3.x packages and some other Python dependencies package many times. At some point, It broke my Arch Linux and pacman stopped working. Whenever I run pacman, I got an error that says «pacman: error while loading shared libraries: libidn2.so.0: cannot open shared object file: No such file or directory».

pacman: error while loading shared libraries: libidn2.so.0: cannot open shared object file: No such file or directory

Not just pacman, some other applications, such as pacaur, yaourt, packer, virtualbox and transmission etc., also stopped working. When I try to open any one of these applications, I keep getting this message — «error while loading shared libraries: libidn2.so.0: cannot open shared object file».

Chances are that I may have uninstall something that I couldn’t remember. To my bad luck, It was my personal system and I don’t want to reinstall it because it has a lot of applications. So, reinstalling OS and all applications might took two or may be more days.

After vigorously searching on Arch Linux wiki and other Linux forums like a mad man, I finally managed to fixed it. If you ever run into a problem something like this, look nowhere, just download the source file and copy the missing file(s) to /usr/lib/ folder. As far as I searched on the web, this method seems very easiest one so far. Read on to know how I fixed this error.

As I said already, I kept getting this error — «pacman: error while loading shared libraries: libidn2.so.0: cannot open shared object file: No such file or directory» when I run pacman command or any AUR helpers such as pacaur, packer, yaourt and I even can’t open VirtualBox application and Transmission client. So, the actual problem here is the file «libidn2.so.0» has gone missing. We need to find it out!

Sample output from my Arch Linux system:

I had «libidn.so», but can’t find «libidn2.so.0». Since pacman and any other package manager didn’t work, there is no way to install, upgrade or downgrade any packages from official repository or local cache. So, I thought that the only way might be to download the package that has the missing file from Internet, extract it and finally copy the missing file(s) to /usr/lib/ directory. Let me create a directory to save libdin2 tar file:

Find and download the latest version of this package. A quick google search brought me here. Extract the file:

The above command extracted the contents of the file in a directory named «usr». Go to the usr/lib folder: (Note — It is usr/lib, not /usr/lib)

Finally copy the missing file, in our case it is libidn2.so.0, to /usr/lib/ directory of your Arch Linux system.

Update Arch Linux

Voila! Pacman works now!! Oops! Oh no, wait.. It didn’t work. I got this error after few minutes.

To fix this, I ran:

Then, I tried update again:

Fixed!! All good now. So, if you guys ever run into an issue something like «error while loading shared libraries: .. cannot open shared object file: No such file or directory», one way to fix this is to find the the package that contains the missing files, download the latest version of that package, extract it and copy the missing files to /usr/lib/ directory. Of course, there could be many ways to fix such kind of issues. But this is the only working solution I could find and I find this much easier and faster. This trick might work on other Linux distros too.

Related read:

Senthilkumar Palani (aka SK) is the Founder and Editor in chief of OSTechNix. He is a Linux/Unix enthusiast and FOSS supporter. He lives in Tamilnadu, India.

Источник

shamashs

04.08.14 — 15:10

Собственно все поднялось, но при перезапуске пишет

vvp@server1c:~$ sudo service srv1cv83 start

[sudo] password for vvp:

Starting 1C:Enterprise 8.3 server: Error: service failed to start!

FAILED

vvp@server1c:~$

Где посмотреть логи, бубунта

ДенисЧ

1 — 04.08.14 — 15:11

/var/log, разумеется

shamashs

2 — 04.08.14 — 15:12

alternatives.log    btmp          fontconfig.log  syslog.1

alternatives.log.1  btmp.1        fsck            syslog.2.gz

apport.log          cups          installer       syslog.3.gz

apport.log.1        dist-upgrade  kern.log        syslog.4.gz

apt                 dmesg         kern.log.1      syslog.5.gz

aptitude            dmesg.0       kern.log.2.gz   syslog.6.gz

aptitude.1.gz       dmesg.1.gz    kern.log.3.gz   syslog.7.gz

auth.log            dmesg.2.gz    landscape       udev

auth.log.1          dmesg.3.gz    lastlog         unattended-upgrades

auth.log.2.gz       dmesg.4.gz    nxserver.log    upstart

auth.log.3.gz       dpkg.log      postgresql      wtmp

boot.log            dpkg.log.1    samba           wtmp.1

bootstrap.log       faillog       syslog          Xorg.0.log

где именно?

shamashs

3 — 04.08.14 — 15:12

при этом процес посгреса запущен

ДенисЧ

4 — 04.08.14 — 15:13

Для начала в syslog

shamashs

5 — 04.08.14 — 15:16

там данные только о запущенном openvpn сервере

shamashs

6 — 04.08.14 — 15:17

допустим я сейчас запущу сервер 1с предприятия в каком из логов он должен оставить сообщение о том что ему недостаточно прав или админ криворукий

shamashs

7 — 04.08.14 — 16:39

скинте хоть статью с итс, где описаны тонкости про такую слышал найти не могу

shamashs

8 — 11.08.14 — 14:48

Starting 1C:Enterprise 8.3 server: /opt/1C/v8.3/x86_64/ragent: error while loading shared libraries: nuke83.so: cannot open shared object file: No such file or directory

это он откуда он хочет чтобы я ему поставил ?

ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку «Обновить» в браузере.

Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.

Источник

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

А вот почему ее нельзя найти и загрузить, это уже интересно. Этому может быть несколько причин:

Библиотека не установлена в системе;
Библиотека установлена, но неизвестно куда;
Библиотека установлена правильно, но имеет не ту версию.

При решении проблемы мы будем руководствоваться именно этими причинами и пытаться их решить.

Как исправить ошибку?

1. Библиотека не установлена

Например, если нам не хватает библиотеки libfuse2.so, то мы можем найти ее в Ubuntu такой командой:

sudo apt search libfuse2

Затем осталось только установить ее:

sudo apt install libfuse2

sudo apt install libfuse-dev

И так для любой библиотеки. Но это не всегда помогает.

2. Библиотека находится не в том каталоге

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

ldconfig -p

locate librtfreader

export LD_LIBRARY_PATH=/opt/kingsoft/wps-office/office6/

ln -s /opt/kingsoft/wps-office/office6/librtfreader.so /usr/lib/librtfreader.so

3. Неверная версия библиотеки

Например, библиотеки 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

sudo ldconfig

Выводы

Статья распространяется под лицензией Creative Commons ShareAlike 4.0 при копировании материала ссылка на источник обязательна .

Источник

Ошибка error while loading shared libraries

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

Что означает error while loading shared libraries?

А вот почему ее нельзя найти и загрузить, это уже интересно. Этому может быть несколько причин:

Библиотека не установлена в системе;
Библиотека установлена, но неизвестно куда;
Библиотека установлена правильно, но имеет не ту версию.

При решении проблемы мы будем руководствоваться именно этими причинами и пытаться их решить.

Как исправить ошибку?

1. Библиотека не установлена

Например, если нам не хватает библиотеки libfuse2.so, то мы можем найти ее в Ubuntu такой командой:

sudo apt search libfuse2

Затем осталось только установить ее:

sudo apt install libfuse2

sudo apt install libfuse-dev

И так для любой библиотеки. Но это не всегда помогает.

2. Библиотека находится не в том каталоге

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

ln -s /opt/kingsoft/wps-office/office6/librtfreader.so /usr/lib/librtfreader.so

3. Неверная версия библиотеки

Например, библиотеки 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

Выводы

Источник

Ошибка error while loading shared libraries в Linux

Естественно, в Вашем случае библиотека может называться иначе. Смотрите, что упоминается в тексте ошибки.

Поищем библиотеку в репозиториях:

В результате мы получим перечень пакетов, которые в названии содержат libatomic:

А можно сделать символьную (символическую) ссылку:

ln -s [путь_к_библиотеке/имя_библиотеки] /usr/lib/[имя_библиотеки]

ln -s [путь_к_библиотеке/настоящее_имя_библиотеки] [путь_к_библиотеке/имя_библиотеки_с_нужной_версией]

Если этот способ не помог, то выход один — искать библиотеку нужной версии.

И последнее: после манипуляций с библиотеками желательно обновить кэш командой

Вот, пожалуй, и всё, что нужно знать про ошибку error while loading shared libraries.

Источник

Arch Linux

You are not logged in.

#1 2010-04-09 17:03:58

[SOLVED] pacman: error while loading shared libraries: libssl.so.0.9.8

some minutes ago I tried to update my system. The pacman-update seems to be broken. Every time I try to use pacman (even basics like -Qi) it gives me:

pacman: error while loading shared libraries: libssl.so.0.9.8: cannot open shared object file: No such file or directory

upgraded pacman (3.3.3-1 -> 3.3.3-5)
upgraded gtk2 (2.20.0-1 -> 2.20.0-2)
upgraded openssl (0.9.8n-1 -> 1.0.0-2)
upgraded xorg-server (1.7.5.902-1 -> 1.7.6-3)

I have no idea what to do? No clue how to downgrade without pacman.

PS: I’m NOT using testing.

Last edited by cl10k (2010-04-10 15:59:20)

#2 2010-04-09 17:09:11

Re: [SOLVED] pacman: error while loading shared libraries: libssl.so.0.9.8

First tell us how did you manage to do this? A -Syu shouldn’t cause that. Is that really the complete log?

#3 2010-04-09 17:37:33

Re: [SOLVED] pacman: error while loading shared libraries: libssl.so.0.9.8

I can confirm that openssl upgrade caused many issues (firefox flash plugin, yaourt , etc.).
As a workaround, I linked the following libs :

/usr/lib/libssl.so.0.9.8 -> /usr/lib/libssl.so
/usr/lib/libcrypto.so.0.9.8 -> /usr/lib/libcrypto.so

but there is something still broken.

#4 2010-04-09 17:41:36

Re: [SOLVED] pacman: error while loading shared libraries: libssl.so.0.9.8

I can confirm that openssl upgrade caused many issues (firefox flash plugin, yaourt , etc.).
As a workaround, I linked the following libs :

/usr/lib/libssl.so.0.9.8 -> /usr/lib/libssl.so
/usr/lib/libcrypto.so.0.9.8 -> /usr/lib/libcrypto.so

but there is something still broken.

this workaround should be ignored. anyone else that have this problem, just be sure you are fully update. a simple pacman -Syu should fix your problems.

Give what you have. To someone, it may be better than you dare to think.

#5 2010-04-09 17:53:01

Re: [SOLVED] pacman: error while loading shared libraries: libssl.so.0.9.8

even with pacman -Syu it is broken

#6 2010-04-09 17:56:29

Re: [SOLVED] pacman: error while loading shared libraries: libssl.so.0.9.8

You very likely did something wrong in the first place.

#7 2010-04-09 18:12:26

Re: [SOLVED] pacman: error while loading shared libraries: libssl.so.0.9.8

What smart2128 did did not work for me

and it works now.
I mean I cant do now a pacman -Syu

If something else is broken I do now know right now

#8 2010-04-09 18:15:18

Re: [SOLVED] pacman: error while loading shared libraries: libssl.so.0.9.8

I wonder if this sort of problem could be caused by installing a package without syncing the database, after your database is out of date. Something like

Doing that sort of thing bit me when I started with Arch.

#9 2010-04-09 18:19:28

Re: [SOLVED] pacman: error while loading shared libraries: libssl.so.0.9.8

What smart2128 did did not work for me

and it works now.
I mean I cant do now a pacman -Syu

If something else is broken I do now know right now

Wonder was right, this isn’t the proper way to solve that issue.
I just pointed the attention on the openssl update.
You did exactly what I wrote because /usr/lib/libssl.so.1.0.0 is a symlink to /usr/lib/libssl.so

gerbra/mirrorcheck.html and using the last synced mirror in mirrorlist.

Last edited by smart2128 (2010-04-10 07:35:27)

#10 2010-04-09 18:30:16

Re: [SOLVED] pacman: error while loading shared libraries: libssl.so.0.9.8

Originally I wanted to make a «pacman -Syu», but when I saw the amount of updates i decided to «pacman -S» only gtk2 and xorg-server.

Right after the upgrade of xorg, pacman refused to work. Here the full log:

[2010-04-09 17:44] synchronizing package lists
[2010-04-09 17:47] upgraded pacman (3.3.3-1 -> 3.3.3-5)
[2010-04-09 18:14] synchronizing package lists
[2010-04-09 18:15] starting full system upgrade
[2010-04-09 18:15] upgraded gtk2 (2.20.0-1 -> 2.20.0-2)
[2010-04-09 18:18] synchronizing package lists
[2010-04-09 18:18] starting full system upgrade
[2010-04-09 18:19] warning: /etc/ssl/openssl.cnf installed as /etc/ssl/openssl.cnf.pacnew
[2010-04-09 18:19] upgraded openssl (0.9.8n-1 -> 1.0.0-2)
[2010-04-09 18:19] upgraded xorg-server (1.7.5.902-1 -> 1.7.6-3)

Last edited by cl10k (2010-04-09 18:31:26)

#11 2010-04-09 18:36:21

Re: [SOLVED] pacman: error while loading shared libraries: libssl.so.0.9.8

and that messed up your system while -Syu would have just worked. pacman -Sy is always dangerous.

Btw: The maintainer of xorg-server should get punched for using a versioned dep to openssl. (Maybe it’s a good idea for real; talking about it and asking them to not use versioned deps doesn’t seem to help)

#12 2010-04-09 18:42:14

Re: [SOLVED] pacman: error while loading shared libraries: libssl.so.0.9.8

(firefox flash plugin, yaourt , etc.).

Hi, after today’s update flashplugin stopped working for me. It crashes whenever I try to play videos for example on youtube, but flash ads work fine. I have tested on several browsers. Do you think that this is related with openssl? I could try to downgrade openssl, but it has many dependencies (xorg-server). I attach a fragment of /var/log/pacman.log

#13 2010-04-09 18:56:09

Re: [SOLVED] pacman: error while loading shared libraries: libssl.so.0.9.8

Could you please be so polite and stop spamming my thread with your problems?!

I would prefer to have my problem sorted here — your free to open your own threads.

Pierre, any ideas how to solve that problem?

#14 2010-04-09 19:02:21

Re: [SOLVED] pacman: error while loading shared libraries: libssl.so.0.9.8

There are several methods. It might work if you temporary create those symlinks mentioned above and run «pacman -S libarchive libfetch pacman», remove the symlinks again and run pacman -Syu.

If those symlinks wont work you could manually download the libarchive and libfetch package and extract them to / using tar (remove the .PKG* and .INSTALL files in / afterwards). Now run pacman -Sf libarchive libfetch and then pacman -Syu.

#15 2010-04-09 19:07:17

Re: [SOLVED] pacman: error while loading shared libraries: libssl.so.0.9.8

I’m not that experienced with linux/commandline but I think I try the symlinks-way first, it sounds easier to me.

#16 2010-04-09 19:35:15

Re: [SOLVED] pacman: error while loading shared libraries: libssl.so.0.9.8

I think it works now. Thank you Pierre and thank you smart2128/csergec for the symlinks!

A general question about updating:

Usually I just run pacman -Syu daily and and don’t fuss with the updates in any other way.
But today there were 48 updates including cups, hplip and texlive which are very important for me. How do you handle big updates with lots of packages? I thought it would be easy to update step by step during the next days and check if one update after another works. What is the savest way to update such a big amount?

#17 2010-04-09 19:42:05

Re: [SOLVED] pacman: error while loading shared libraries: libssl.so.0.9.8

cherry picking packages is always a bad idea (and -Sy

should _never_ be done). update daily and fully. deal with problems as they arise. since arch is rolling release, the repos/packages have to be maintained under the assumption that everyone is fully up to date at all times. if you stay away from [testing] it is very very rare that an update will break anything*.

*two caveats here: aur packages and out of date/half-synced mirrors. both can be solved with a rebuild or a new-mirror, -Syyu respectively.

#18 2010-04-09 19:44:31

Re: [SOLVED] pacman: error while loading shared libraries: libssl.so.0.9.8

The safest way is «pacman -Syu»! Any other way is likely to break something or other. I just updated 56 packages without an issue. The problem may be that your mirrors are not in sync or you are using packages from the AUR which have not been updated.

All men have stood for freedom.
For freedom is the man that will turn the world upside down.
Gerrard Winstanley.

#19 2010-04-09 20:04:13

Re: [SOLVED] pacman: error while loading shared libraries: libssl.so.0.9.8

This happened to me when in the middle of this 1.3GB upgrade I hit ctrl+c as I wanted to copy the content of the terminal window (I know it’s a pretty bad idea). Then I tried to pacman again but it needed openssl-0.9.8. I then created a symlink to new libssl-1.0 and libcrypto-1.0 and was able to continue my upgrade. In the end I removed the temporary symlinks and apparently I’m back on tracks.

#20 2010-04-09 20:48:08

Re: [SOLVED] pacman: error while loading shared libraries: libssl.so.0.9.8

This is quite funny, some days ago I did:

And I found myself in the same situation, I found that the problem was because of xorg-server that installed a new openssl as dependency, the big problem was that pacman also didn’t work.

But not a big problem, these days a always have a recent backup of my system (thanks to rsync) I just copied the files of libssl and libcrypt to get pacman functional and with pacman repaired the damaged 😉

#21 2010-04-09 21:27:51

Re: [SOLVED] pacman: error while loading shared libraries: libssl.so.0.9.8

Oops, i was in the middle of a ‘pacman -Syu’ as i do every day, and there was a power outage that let me with a similar scenario here, solved with the temporary linking of that two libs.

Thanks to help me to solve this problem too.

#22 2010-04-10 00:50:57

Re: [SOLVED] pacman: error while loading shared libraries: libssl.so.0.9.8

As for Flash not working — if you have libssh2 from AUR you need to rebuild it AFTER you upgrade today’s openssl package. That can cause Flash to fail and take Firefox with it! (I got bit by it today!)

«It is very difficult to educate the educated.»

#23 2010-04-10 00:54:05

Re: [SOLVED] pacman: error while loading shared libraries: libssl.so.0.9.8

Ugh. I guess I broke something good. I did the quick and dirty symlink trick mentioned above and updated again, which didn’t update anything important. Then I deleted the symlink, or so I thought.

But then I realized that was just gonna delete the libssl.so.1.0.0 file. AWESOME.

Does anybody just have the 64bit libssl.so.1.0.0 file they want to send me so I can just drop it into the directory and pray?

Ha. Nevermind. I fixed it by extracting the cached package and just dropping the files into the proper directory after destroying those stupid symlinks.

Even as much as I screw stuff up, I’ll never have to reinstall this distro.

Last edited by pogeymanz (2010-04-10 01:46:44)

#24 2010-04-10 09:42:32

Re: [SOLVED] pacman: error while loading shared libraries: libssl.so.0.9.8

wow same problem here but solved using the symbolic links from 1.0.0 to 0.9.8 and then revert to old version with

pacman -U /var/cache/pacman/pkg/openssl-0.9.8n-1-x86_64.pkg.tar.xz

then pacman -Syu and everything ok.

I got to the problem by upgrading just openssl by

pacman -S openssl

that was because i installed Apache and it complained when started that was broken mod_ssl and libssl and it needed openssl-1.0.0

thanks for the symbolic links trick!!

Last edited by sergi34 (2010-04-10 09:43:28)

#25 2010-04-10 11:01:44

Re: [SOLVED] pacman: error while loading shared libraries: libssl.so.0.9.8

I would prefer to have my problem sorted here — your free to open your own threads.

You are right, sorry.
But, I just want mention that my problem with flash (with quake live plugin too) was also caused by openssl. I struggled with it since yesterday and I found that package openssl-compatibility (which includes libssl and libcrypto 0.9.8 libs) from AUR fixes it

Источник

Tux Многие пользователи Linux рано или поздно сталкиваются с ошибкой error while loading shared libraries. Как правило, при установке программ вручную. Сегодня поговорим об исправлении данной ошибки. Для примера возьмём старый ноутбук с Ubuntu 14.04 LTS, поддержка которой недавно закончилась, а значит что-то приходится доустанавливать вручную.

locate *libatomic*

Естественно, в Вашем случае библиотека может называться иначе. Смотрите, что упоминается в тексте ошибки.

Поищем библиотеку в репозиториях:

sudo apt search libatomic

В результате мы получим перечень пакетов, которые в названии содержат libatomic:

sudo apt install libatomic1

А можно сделать символьную (символическую) ссылку:

ln -s [путь_к_библиотеке/имя_библиотеки] /usr/lib/[имя_библиотеки]

ln -s [путь_к_библиотеке/настоящее_имя_библиотеки] [путь_к_библиотеке/имя_библиотеки_с_нужной_версией]

Если этот способ не помог, то выход один — искать библиотеку нужной версии.

И последнее: после манипуляций с библиотеками желательно обновить кэш командой

sudo ldconfig

Вот, пожалуй, и всё, что нужно знать про ошибку error while loading shared libraries.

Источник

There is a list of common errors I often see in Ubuntu. There is problem with merge list, then there is BADSIG error, and a number of common Ubuntu update errors.

One of such common errors which I often see while installing a program from its source code is error while loading shared libraries. The full error generally looks like this:

error while loading shared libraries:
cannot open shared object file: No such file or directory

For example, I was trying to use FreeRADIUS server and it showed me this error:

radiusd: error while loading shared libraries:
libfreeradius-radius-2.1.10.so:
cannot open shared object file: No such file or directory

The reason behind this error is that the libraries of the program have been installed in a place where dynamic linker cannot find it.

Let me show you how you can go about fixing this issue.

One quick way to fix this “error while loading shared libraries” automatically is to use ldconfig.

All you need to do is to open terminal (Ctrl+Alt+T) and type the following command:

sudo /sbin/ldconfig -v

This one liner should solve the problem in most cases. However, if it doesn’t, I have discussed another method to handle this error. But before that, let me tell you what does the above command do.

What are shared object files? How does the above command fixes the issue?

You see, in C/C++, a .so (shared object) is a compiled library file. It is called shared object because this library file can be shared by several programs. These generated libraries are usually located in /lib or /usr/lib directories.

Now if you wonder how did this tiny command fixed this problem, you should read the man page of ldconfig which says:

ldconfig creates the necessary links and cache to the most recent shared libraries found in the directories specified on the command line, in the file /etc/ld.so.conf, and in the trusted directories (/lib and /usr/lib). The cache is used by the run-time linker, ld.so or ld-linux.so. ldconfig checks the header and filenames of the libraries it encounters when determining which versions should have their links updated.

I hope this quick fix helps you in eliminating the nasty error while loading shared libraries message in Ubuntu and other Linux.

If not, you can do some investigation and try to fix the issue the way it is mentioned in the next section.

The above discussed method fixes the issue if the library in question is available in your system. But that may not always be the case.

If you do not have the program installed on your system, you won’t have its library file. The ldconfig cannot do anything if there is no library file in the first place.

So, the alternate method is to install the required program and it should create the library automatically.

Let me show it to you by an example. Let’s say you see this error:

error while loading shared libraries: libgobject-2.0.so.0: cannot open shared object file: No such file or directory

The problem is with libgobject version 2.0. The version number is important because some programs depend on a specific version of the library and if they don’t find, they complain about it.

Now, apt provides the search option that can be used for searching a package and knowing its version before installing it.

[email protected]:~$ apt search libgobject
Sorting... Done
Full Text Search... Done
librust-gobject-sys-dev/focal 0.9.0-2 amd64
  FFI bindings to libgobject-2.0 - Rust source code

Now, this librust-gobject-sys-dev package could be what you need if you know that you were trying to run a Rust program. But what if it was a Python program you were running that complained about it?

You can widen your search by removing the lib from the package name while searching. The lib signifies library and libraries may be provided by a generic package that could be named gobject-xyz.

It would be a good idea to search for the string in the names of the package (instead of description) to get more concise results.

[email protected]:~$ apt search --names-only gobject
Sorting... Done
Full Text Search... Done
gobject-introspection/focal-updates 1.64.1-1~ubuntu20.04.1 amd64
  Generate interface introspection data for GObject libraries

libavahi-gobject-dev/focal 0.7-4ubuntu7 amd64
  Development headers for the Avahi GObject library

libavahi-gobject0/focal 0.7-4ubuntu7 amd64
  Avahi GObject library

libcairo-gobject-perl/focal,now 1.005-2 amd64 [installed,automatic]
  integrate Cairo into the Glib type system in Perl

libcairo-gobject2/focal,now 1.16.0-4ubuntu1 amd64 [installed,automatic]
  Cairo 2D vector graphics library (GObject library)

libghc-gi-gobject-dev/focal 2.0.19-1build1 amd64
  GObject bindings

libghc-gi-gobject-doc/focal,focal 2.0.19-1build1 all
  GObject bindings; documentation

In the above truncated output, you’ll have to see if the package is related to the original program you were trying to run. You must also check the version of the library provided.

Once you have identified the correct package, install it like this:

sudo apt install package_name

Once installed, you may run the ldconfig command again to update the cache:

sudo /sbin/ldconfig -v

This method requires some effort on your end but this is how the dependencies are handled.

Nothing works, what now?

If you are unfortunate enough, the above methods might not work for you. What can you do?

First, keep in mind that the shared libraries may be used from other packages in some cases. If you were trying to run XYZ program and ABC program installs the correct version of the shared library, it may (or may not) work for you. You can give it a hit and trial.

Second, if you are trying to run a program which is too old or too new, it may require a library version which is not available for your Linux distribution.

What you may do is to check if you can use some other version of the program. For example, using Eclipse version 3 instead of version 4. This may help your case.

The other way would be to check the developers website or forums and see if you can manually install the correct version of the library from its source code. That requires a lot of effort (in 2020) but you don’t have a lot of options.

Did it work for you?

I hope I have make things a bit more clear for you. Did you manage to fix the issue of shared libraries in your system? If you have questions, suggestions, feel free to drop a comment. Ciao

Источник

Wondering how to fix Nginx error while loading shared libraries? We can help you.

Often Nginx users report that they end up with this error while trying to start Nginx. Nginx is open-source software for web serving, reverse proxying, caching, load balancing, media streaming, etc.

Here at Bobcares, we handle requests from our customers using Nginx servers to fix similar issues as a part of Server Management Services.

Today, let us see how our Support techs resolve this issue for our customers.

What causes ‘Nginx error while loading shared libraries’

A typical error looks like the one given below:

Starting nginx: /opt/nginx/sbin/nginx: error while loading shared libraries: libpcre.so.1: cannot open shared object file: No such file or directory

The Nginx executable was compiled to expect the PCRE (Perl-compatible Regular Expression) shared library to be available somewhere on LD_LIBRARY_PATH or specified in /etc/ld.so.conf or whatever equivalent library-locating mechanisms apply to our operating system and it cannot find the library.

Common causes for this error is given below:

1. PCRE library not available

2. Nginx compiled installation did not specify the correct PCRE address

3. Did not add PCRE library to LD_LIBRARY_PATH

How to fix ‘Nginx error while loading shared libraries’

To fix this error we need to install PCRE.

Nginx is looking for a file libpcre.so.1 which comes under the PCRE library and usually installed on UNIX.

We can find libpcre.so.1 using the following find command:

$find / -name libpcre.so.1 /usr/local/lib/libpcre.so.1

If this file is present, it means that PCRE is already installed.

In case, if we do not get find results, we will have to install PCRE using the following command:

yum install pcre

Now, we have to set LD_LIBRARY_PATH, as we could see libpcre.so.1 is available under /usr/local/lib.

$export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH

Start Nginx using either of the following commands:

sudo systemctl start nginx or sudo service nginx start

If Nginx does not specify the correct PCRE address, we need to recompile and install Nginx and specify PCRE.

We do this using the following commands:

./configure –prefix=/usr/local/nginx –with-pcre=../pcre-8.38 make sudo make install

[Need assistance? We can help you]

Conclusion

In short, we saw how our Support Techs fix ‘Nginx error while loading shared libraries’ for our customers.

PREVENT YOUR SERVER FROM CRASHING!

Never again lose customers to poor server speed! Let us help you.

Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.

GET STARTED

var google_conversion_label = «owonCMyG5nEQ0aD71QM»;

Источник