При связывании с неопределенной версией библиотеки правильный выбор?

С strace я вижу, что программе нужна некоторая неопределенная версия библиотеки gmp :

 open("/lib/x86_64-linux-gnu/libgmp.so", O_RDONLY|O_CLOEXEC) = \ -1 ENOENT (No such file or directory) 

Я думаю, что он должен быть связан с конкретной версией интерфейса (например, libgmp.so.10 например).

Однако это не похоже на обычную практику. Это случайно или есть веская причина полагаться на неуказанную версию?

Единственным приемлемым случаем, о котором я могу думать, является дистрибутив ОС: вы строите (и контролируете) каждый пакет.

  • Как использовать 32-битный скомпилированный файл общих объектов (.so) на 64-битном RHEL?
  • общая библиотека не найдена даже при обновленном ld.so.conf
  • Почему ldd показывает это динамическое расположение компоновщика?
  • Можете ли вы изменить цель динамической ссылки без перекомпиляции?
  • Поиск абсолютного пути разделяемых библиотек, используемых исполняемым файлом
  • Есть ли механизм, который защищает приложения во время обновления библиотеки?
  • Влияние статической и динамической привязки на начальный адрес
  • Каков порядок, в котором динамический компоновщик Linux ищет пути?
  • One Solution collect form web for “При связывании с неопределенной версией библиотеки правильный выбор?”

    Я бы не сказал «неприемлемый», но для двоичного файла определенно необычно искать общую библиотеку под простым *.so именем во время выполнения. Как правило:

    • Компилятор (время сборки) ищет библиотеки под именами, соответствующими *.so
    • Если найден, линкер обращается к полю SONAME библиотеки, чтобы узнать имя, которое должна быть расположена в библиотеке во время выполнения
    • Он записывает это имя внутри встроенного двоичного файла, чтобы он выполнялся во время выполнения.

    Цель этого соглашения заключается в том, что двоичный файл может быть привязан к конкретной версии API-библиотеки.

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

     objdump -p /lib/`arch`-linux-gnu/libthing.so | fgrep SONAME 

    Если SONAME не существует, тогда двоичные файлы, связанные с этой библиотекой, по умолчанию будут использовать имя, под которым библиотека была найдена во время сборки (которая равна *.so ). Это может быть то, что вы видите. Если существует SONAME, тогда двоичные файлы, связанные с этой библиотекой, должны были использовать это имя во время выполнения.

    Interesting Posts

    Расширенный поиск и замена программы

    Каков второй столбец ls -l?

    Сообщение об ошибке «дата: неверная дата» 2016-10-16 »

    Добавить путь к имени файла

    как объединить наложения дерева устройств с одним .dtb во время сборки?

    Могу ли я деактивировать драйвер Broadcom, если у меня есть карта беспроводной сети Realtek?

    Debian-Windows с двойной загрузкой: какой я должен установить первым?

    Оформление моего окна x другому процессу

    Kali linux с двойной загрузкой с выигрышем 8 64 бит не работает

    Как отменить выбор пакетов определенной архитектуры в aptitude

    Невозможно выполнить umount / mnt

    Есть ли утилита для демонтизации процессов в пользовательском пространстве?

    как удалить все файлы с определенным расширением в определенных именованных папках в большом дереве?

    Когда gitlab говорит сделать исполняемый файл, что именно они означают?

    более длинная строка для tr вызывает зависание и всплеск процессора

    Linux и Unix - лучшая ОС в мире.