Ошибка «cannot open shared object file»: причины и решение

Что означает ошибка «cannot open shared object file»

Ошибка с текстом error while loading shared libraries: <имя_библиотеки>.so: cannot open shared object file: No such file or directory (или её варианты, такие как ld-linux.so not found) — это критическое сообщение от динамического загрузчика Linux (ld-linux.so или ld.so).

Она означает, что система не смогла найти необходимую общую (shared) библиотеку (файл с расширением .so) во время попытки запуска исполняемого файла (программы, утилиты, другого бинарника). Динамический загрузчик отвечает за разрешение зависимостей программы от внешних библиотек. Если нужный файл не обнаружен в заданных путях, запуск прерывается.

Полный текст типичной ошибки:

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

Здесь libssl.so.1.1 — отсутствующая библиотека.

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

1. Библиотека не установлена. Самая частая причина. Программа требует конкретную версию библиотеки (например, libssl.so.1.1), которая отсутствует в системе.
2. Библиотека установлена, но в нестандартном пути. Загрузчик ищет библиотеки только в путях, указанных в /etc/ld.so.conf и файлах в /etc/ld.so.conf.d/, а также в стандартных (/lib, /usr/lib). Если библиотека лежит, например, в /opt/custom/lib, она не будет найдена.
3. Устарел кэш загрузчика (/etc/ld.so.cache). Даже если библиотека лежит в правильном месте, загрузчик использует скомпилированный кэш. После установки новой библиотеки кэш нужно обновить командой ldconfig.
4. Конфликт/повреждение пакета. Библиотека могла быть удалена или повреждена при обновлении/удалении другого пакета.
5. Несовместимость архитектуры или версии glibc. Попытка запустить 32-битную программу на чисто 64-битной системе без установки 32-битных библиотек (:i386 пакеты в Debian/Ubuntu). Или программа скомпилирована под очень старую/новую версию библиотеки, которой нет в текущем релизе дистрибутива.
6. Повреждённые символические ссылки. В папке с библиотеками могут быть битые ссылки libssl.so -> libssl.so.1.1, указывающие на несуществующий файл.

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

Способ 1: Обновление кэша загрузчика (самое простое и частое)

Это первый и обязательный шаг после установки любой новой библиотеки.

1. Откройте терминал.
2. Выполните команду с правами суперпользователя:

   sudo ldconfig
   

3. Попробуйте запустить программу снова.

Что делает ldconfig: Он сканирует все каталоги, перечисленные в конфигурационных файлах /etc/ld.so.conf и /etc/ld.so.conf.d/*.conf, находит там библиотеки (файлы lib*.so*), обновляет (или создаёт) кэш /etc/ld.so.cache и обновляет символические ссылки. После этого загрузчик знает, где искать все установленные библиотеки.

💡 Совет: Если вы только что установили пакет через менеджер пакетов (apt, dnf), он обычно сам вызывает ldconfig. Но если вы вручную скопировали .so файл в /usr/local/lib — ldconfig выполнить обязательно.

Способ 2: Установка недостающего пакета

Если библиотеки физически нет в системе, её нужно установить.

Для Debian/Ubuntu и производных:

1. Найдите имя пакета, который предоставляет нужную библиотеку. Самый точный способ:

   apt-file search libssl.so.1.1 | head -n 5
   

   
   Если apt-file не установлен, сначала выполните sudo apt update && sudo apt install apt-file && sudo apt-file update.
2. Установите пакет (пример для libssl.so.1.1):

   sudo apt update
   sudo apt install libssl1.1
   

   
   Или, если требуется более новая версия:

   sudo apt install libssl3
   

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

Для CentOS/RHEL/Fedora/Rocky/AlmaLinux:

1. Найдите пакет:

   yum provides "*/libssl.so.1.1"
   # или для dnf
   dnf provides "*/libssl.so.1.1"
   

2. Установите найденный пакет (например, openssl-libs):

   sudo dnf install openssl-libs
   

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

Способ 3: Добавление нестандартного пути в конфигурацию ld.so

Если библиотека лежит в кастомной папке (например, вы скомпилировали и установили программу в /opt/myapp/lib).

1. Создайте новый конфигурационный файл (рекомендуется) или отредактируйте существующий:

   sudo nano /etc/ld.so.conf.d/custom-apps.conf
   

   
   Добавьте в файл одну строку с полным путём к папке, содержащей .so файлы:

   /opt/myapp/lib
   

   
   Можно добавить несколько путей, каждый с новой строки.
2. Примените изменения:

   sudo ldconfig
   

3. Проверьте, что путь добавился в кэш:

   ldconfig -p | grep myapp
   

⚠️ Важно: Не добавляйте в /etc/ld.so.conf пути к временным или недоверенным каталогам. Это вопрос безопасности.

Способ 4: Использование переменной окружения LD_LIBRARY_PATH (временное решение)

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

1. Установите переменную окружения перед запуском команды:

   LD_LIBRARY_PATH="/путь/к/папке_с_библиотеками:$LD_LIBRARY_PATH" ./ваша_программа
   

   
   Пример:

   LD_LIBRARY_PATH="/home/user/app/lib:$LD_LIBRARY_PATH" ./myapp
   

2. Для постоянного использования (только для текущего пользователя) добавьте строку в ~/.bashrc или ~/.profile:

   export LD_LIBRARY_PATH="/home/user/app/lib:$LD_LIBRARY_PATH"
   

   
   После этого выполните source ~/.bashrc или перезайдите в систему.

⚠️ Предупреждение: Избегайте глобального (системного) использования LD_LIBRARY_PATH в /etc/profile. Это может сломать системные утилиты. Используйте только для конкретных приложений или в пользовательских скриптах.

Способ 5: Переустановка или настройка RPATH конкретного бинарника (продвинутый)

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

1. Установите patchelf:

   # Debian/Ubuntu
   sudo apt install patchelf
   # CentOS/RHEL/Fedora
   sudo dnf install patchelf
   

2. Проверьте текущий RPATH (встроенный путь поиска библиотек) бинарника:

   patchelf --print-rpath ./ваша_программа
   

3. Установите нужный RPATH (например, $ORIGIN/lib для поиска в папке lib рядом с бинарником):

   patchelf --set-rpath '$ORIGIN/lib' ./ваша_программа
   

4. Теперь бинарник будет искать библиотеки в указанном относительном пути, независимо от системных настроек.

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

• Устанавливайте пакеты только из официальных репозиториев вашего дистрибутива. Это гарантирует совместимость библиотек.
• Не удаляйте системные библиотеки вручную. Всегда используйте менеджер пакетов (apt remove, dnf remove).
• После ручной установки ПО (из исходников, в /usr/local) всегда выполняйте sudo ldconfig, если установщик не сделал это сам.
• Используйте изолированные среды (например, conda, virtualenv для Python, docker контейнеры, flatpak, snap) для приложений с нестандартными зависимостями. Это не даст им конфликтовать с системными библиотеками.
• При компиляции из исходников используйте флаги ./configure --prefix=/usr/local (или другой чистый путь) и затем make install. Стандартные пути (/usr/local/lib) уже учтены в ld.so.conf.d.
• Периодически обновляйте систему (sudo apt update && sudo apt upgrade, sudo dnf upgrade), чтобы получать актуальные и совместимые версии библиотек.