Удовлетворительная зависимость lib

Вопрос новобранец: у меня есть программа (которую я назову здесь foo ), скомпилированный для x64 (моя текущая арка). Когда я пытаюсь запустить его, он идет:

 ./foo: error while loading shared libraries: libgmp.so.3: cannot open shared object file: No such file or directory 

Соответствующая часть вывода locate :

 /usr/lib/x86_64-linux-gnu/libgmp.so /usr/lib/x86_64-linux-gnu/libgmp.so.10 /usr/lib/x86_64-linux-gnu/libgmp.so.10.1.3 

Оглядевшись , я нашел вопрос Mint: правильный способ установки /lib/i386-linux-gnu/libgmp.so.3 , автор которого говорит: «У меня есть 32-битный двоичный файл, которому требуется libgmp.so.3 на x86_64 монтаж." В этом потоке они предлагают установить скомпилированный для 32-разрядного пакета Ubuntu версии, который я сделал, только для добавления /usr/lib/libgmp.so.3 и /usr/lib/libgmp.so.3.5.2 для locate libgmp и (как и следовало ожидать) изменить ошибку на

 ./foo: error while loading shared libraries: libgmp.so.3: wrong ELF class: ELFCLASS32 

Поэтому я написал двоичного автора, который очень хорошо перекомпилировался, но написал мне, сказав, что библиотека теперь составляет 140 МБ, поэтому лучшим вариантом является перекомпиляция.

Теперь приходят вопросы новичков (я хочу понять, насколько я знаю):

Почему бинарная зависимость от libgmp.so.3 удовлетворяет libgmp.so.10 ?

Означает ли это, что программное обеспечение зависит только от определенной версии библиотеки? Не может ли это быть «мягко-кодированным»?

Совпадает ли общая библиотека с предыдущей версией (я думал, что нет)?

Мои параметры, как я их воспринимаю:

а. Загрузка и компиляция libgmp.so.3 для x64

б. Перекомпиляция программного обеспечения

с. Выполнение рисков: смогу ли я написать ссылку для использования libgmp.so.10 (как бы libgmp.so.3 )?

Будут ли они работать? Каковы будут плюсы и минусы?

PS:

Дополнительно: ldd для корзины

 linux-vdso.so.1 => (0x00007fff290fa000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f8061064000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f8060e46000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f8060b3f000) libbz2.so.1 => /lib/x86_64-linux-gnu/libbz2.so.1 (0x00007f806092f000) llibz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f8060716000) libgmp.so.3 => not found libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8060350000) /lib64/ld-linux-x86-64.so.2 (0x00007f80612a0000) 

One Solution collect form web for “Удовлетворительная зависимость lib”

Из вашего вывода ldd это не похоже на то, что /usr/lib/x86_64-linux-gnu/ находится на пути, который ld знает для поиска разделяемых библиотек. Вы можете проверить это, запустив ldconfig -v с привилегиями суперпользователя, который ldconfig -v список всех разделяемых библиотек, которые может найти LD. Если вы не можете найти libgmp в этом списке, вам нужно отредактировать файл /etc/ld.so.conf.d/[your-system-arch].conf чтобы поместить /usr/lib/x86_64-linux-gnu/ in путь поиска библиотеки.

  • Приложение не может выполнить из-за проблемы с общей библиотекой
  • Какова правильная компоновка символических ссылок, позволяющих совместно использовать совместно используемые библиотеки openssl 1.1.0 и 1.0.2?
  • Как проверить, установлена ​​ли общая библиотека?
  • Как добавить зависимости в библиотеке debian / control?
  • Существует ли стандартный / общепринятый способ для библиотеки плагинов идентифицировать свое местоположение на диске?
  • Почему некоторые файлы рабочих пакетов возвращают «не найдены» для некоторых библиотек вывода ldd?
  • Связь между ldconfig и ld.so.cache
  • Можно ли использовать несколько ветвей одной и той же библиотеки для создания нескольких программных модулей, для которых требуется разная версия этой библиотеки?
  • Текстовый файл занят при копировании некоторых файлов
  • libssl.so.0.9.8: невозможно открыть файл общих объектов: нет такого файла или каталога
  • Как установить путь локальной общей библиотеки после установки возможностей файлов в Debian?
  • Linux и Unix - лучшая ОС в мире.