Ошибка library-not-found в Linux: причины и 5 способов исправления

Что означает ошибка library-not-found

Ошибка library-not-found (часто видно как error while loading shared libraries: libxxx.so: cannot open shared object file: No such file or directory) возникает, когда динамический линковщик Linux (ld.so) не может locate необходимую shared-библиотеку (файл с расширением .so) во время запуска программы.

Типичный сценарий: Вы пытаетесь запустить скомпилированное приложение или скрипт, и вместо выполнения получаете сообщение вида:

./myapp: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory

Система нашла исполняемый файл myapp, но для его работы требуется библиотека libssl.so.1.1, которой нет в путях, которые проверяет линковщик.

Причины возникновения

1. Отсутствующий пакет с библиотекой. Самая частая причина. Необходимый пакет (например, libssl-dev или openssl) не установлен в системе.
2. Библиотека установлена, но в нестандартном пути. Динамический линковщик по умолчанию ищет библиотеки только в /lib, /usr/lib, /usr/local/lib и их архитектурных поддиректориях (например, /usr/lib/x86_64-linux-gnu). Если библиотека лежит в /opt/lib или домашней директории, она не будет найдена.
3. Несоответствие архитектур. Вы пытаетесь запустить 32-битное приложение, а установлена только 64-битная версия библиотеки (или наоборот).
4. Повреждение или неполная установка пакета. Файлы библиотеки могли быть удалены или повреждены.
5. Устаревшая версия библиотеки. Приложение требует конкретную версию (например, libssl.so.1.1), а в системе установлена более новая (libssl.so.3) или, наоборот, более старая. Симлинки могут быть не настроены корректно.
6. Пропущен шаг ldconfig. После ручной установки библиотеки в стандартный путь необходимо обновить кэш линковщика.

Способы решения

Способ 1: Установка недостающего пакета через менеджер пакетов (рекомендуемый)

Это самый правильный и системный способ, так как менеджер пакетов сам позаботится о зависимостях, путях и обновлении кэша.

1. Определите, какого пакета не хватает. Используйте команду ldd на проблемном исполняемом файле. Она покажет все зависимости и отметит те, которые не найдены.

   ldd /путь/к/вашему/исполняемому_файлу
   

   
   Пример вывода:

   linux-vdso.so.1 (0x00007ffd5b9f8000)
   libssl.so.1.1 => not found
   libcrypto.so.1.1 => not found
   libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8c1a000000)
   /lib64/ld-linux-x86-64.so.2 (0x00007f8c1a400000)
   

   
   Здесь не хватает пакетов, предоставляющих libssl.so.1.1 и libcrypto.so.1.1.
2. Найдите пакет, содержащий библиотеку. Для Debian/Ubuntu используйте apt-file. Сначала установите его, если не установлен: sudo apt update && sudo apt install apt-file. Затем обновите базу и ищите:

   sudo apt-file update
   apt-file search libssl.so.1.1
   

   
   Вывод будет содержать строки вида:

   libssl1.1: /usr/lib/x86_64-linux-gnu/libssl.so.1.1
   libssl1.1: /usr/lib/x86_64-linux-gnu/libssl.so.1.1.0
   

   
   Имя пакета — libssl1.1.
   Для RHEL/CentOS/Fedora используйте yum provides или dnf provides:

   yum provides "*/libssl.so.1.1"
   

   
   Для Arch Linux:

   pacman -Fy libssl.so.1.1
   

3. Установите найденный пакет.
   • Debian/Ubuntu:

     sudo apt install libssl1.1
     

   • RHEL/CentOS 7/8:

     sudo yum install openssl-libs
     

   • Fedora:

     sudo dnf install openssl-libs
     

   • Arch Linux:

     sudo pacman -S openssl
     

4. Обновите кэш линковщика (обычно делается автоматически при установке пакета, но для верности):

   sudo ldconfig
   

5. Запустите приложение снова. Ошибка должна исчезнуть.

Способ 2: Ручная установка библиотеки из исходников

Если нужной версии библиотеки нет в репозиториях вашего дистрибутива, можно установить её вручную.

1. Скачайте исходный код библиотеки с официального сайта или GitHub (например, для OpenSSL: https://www.openssl.org/source/).
2. Распакуйте архив и перейдите в директорию:

   tar -xzf openssl-1.1.1w.tar.gz
   cd openssl-1.1.1w
   

3. Сконфигурируйте, скомпилируйте и установите. Обычно используется префикс /usr/local (стандартный путь, который уже в кэше ldconfig). Для 64-битной системы:

   ./config --prefix=/usr/local --openssldir=/usr/local/openssl shared
   make -j$(nproc)
   sudo make install
   

   Ключ shared важен — он собирает shared-библиотеки (.so), а не только статические (.a).
4. Обновите кэш:

   sudo ldconfig
   

5. Проверьте наличие файла библиотеки: ls -l /usr/local/lib/libssl.so.1.1.

Способ 3: Добавление нестандартного пути через LD_LIBRARY_PATH

Если библиотека уже есть в системе, но лежит в нестандартном месте (например, вы установили её в ~/mylibs), можно временно "подсказать" линковщику, где её искать.

1. Установите переменную среды LD_LIBRARY_PATH. Добавьте путь к директории с библиотеками в начало списка:

   export LD_LIBRARY_PATH=/home/ваш_пользователь/mylibs:$LD_LIBRARY_PATH
   

   • Важно: Путь должен указывать на директорию, содержащую .so файлы, а не на сам файл.
   • Эта настройка действует только в текущей оболочке. Для постоянного эффекта добавьте строку в ~/.bashrc, ~/.zshrc или ~/.profile.
2. Запустите приложение из той же сессии терминала. Оно теперь сможет найти библиотеки.
3. Для отладки можно посмотреть, какие пути проверяются, с помощью ldd (он теперь учтёт LD_LIBRARY_PATH) или LD_DEBUG=libs ./ваше_приложение.

Способ 4: Создание символических ссылок (symlinks)

Если у вас есть библиотека нужной версии, но с другим именем (например, libssl.so.1.1.0 вместо libssl.so.1.1), создайте symlink.

1. Найдите реальный файл библиотеки:

   sudo find /usr -name "libssl.so*" 2>/dev/null
   

   
   Пример вывода: /usr/lib/x86_64-linux-gnu/libssl.so.1.1.0.
2. Создайте symlink в директории, которая уже в кэше (например, /usr/lib/x86_64-linux-gnu/):

   cd /usr/lib/x86_64-linux-gnu
   sudo ln -s libssl.so.1.1.0 libssl.so.1.1
   sudo ln -s libcrypto.so.1.1.0 libcrypto.so.1.1  # если нужно и для неё
   

3. Обновите кэш:

   sudo ldconfig
   

Способ 5: Пересборка приложения с правильными путями

Если вы компилируете приложение из исходников самостоятельно, убедитесь, что линковщик знает, где искать библиотеки во время сборки.

1. Установите -dev/-devel пакеты. Они содержат заголовочные файлы (.h) и symlinks для компиляции (например, libssl-dev для OpenSSL).

   sudo apt install libssl-dev  # Debian/Ubuntu
   sudo yum install openssl-devel  # RHEL/CentOS
   

2. При сборке используйте флаги компилятора. Обычно pkg-config автоматически подставляет правильные пути:

   gcc myapp.c -o myapp $(pkg-config --cflags --libs openssl)
   

   
   Или укажите явно:

   gcc myapp.c -o myapp -I/usr/include/openssl -L/usr/lib/x86_64-linux-gnu -lssl -lcrypto
   

   • -I — путь к заголовкам.
   • -L — путь к библиотекам (во время линковки).
   • -l — имя библиотеки без префикса lib и расширения .so.
3. Собранное приложение будет искать библиотеки в стандартных системных путях, и ошибка library-not-found маловероятна.

Профилактика

• Используйте пакетные менеджеры (apt, yum, pacman) для установки библиотек. Они гарантируют корректное размещение и учёт зависимостей.
• Проверяйте зависимости перед сборкой. Для программ на C/C++ используйте pkg-config --exists <библиотека> или проверяйте наличие заголовочных файлов (#include <lib.h>).
• Документируйте кастомные пути. Если вы устанавливаете библиотеки в нестандартные места (например, в /opt/), обязательно фиксируйте это и настраивайте LD_LIBRARY_PATH или добавляйте конфигурационные файлы в /etc/ld.so.conf.d/ (после чего требуется sudo ldconfig).
• Регулярно обновляйте систему: sudo apt update && sudo apt upgrade. Это помогает избежать конфликтов версий.
• Перед запуском стороннего бинарного файла проверяйте его зависимости через ldd и убеждайтесь, что все библиотеки найдены (=> /путь/к/файлу вместо => not found).

💡 Совет: Для постоянного добавления нестандартного пути (например, /usr/local/lib) в поиск ld.so создайте файл конфигурации:

echo "/usr/local/lib" | sudo tee /etc/ld.so.conf.d/usr-local.conf
sudo ldconfig

Это более чистое решение, чем использование LD_LIBRARY_PATH в глобальной среде.