GCC: Определение минимального Shared Library версии

Question

фон

я унаследовал и поддерживать общую библиотеку Linux, которая очень тесно связаны с конкретными аппаратными средствами; назовем это libfoo.so.0.0.0. Эта библиотека была в течение некоторого времени и «просто сработала». Эта библиотека теперь стала зависимой для нескольких приложений более высокого уровня.

Теперь, к сожалению, новые конструкции оборудования заставили меня создавать символы с более широкими типами, в результате чего получается libfoo.so.0.1.0. Были только дополнения; никакие удаления или другие изменения API. Оригинальные узкие версии обновленных символов все еще существуют в их первоначальной форме.

Кроме того, у меня есть приложение (скажем, myapp), которое зависит от libfoo. Первоначально он был написан для поддержки версии библиотеки 0.0.0, но теперь она была переработана для поддержки новых API-интерфейсов 0.1.0.

Для соображений обратной совместимости, я хотел бы иметь возможность построить myapp для старой или новой библиотеки с помощью флага компиляции. Ядро, в которое будет загружена данная сборка myapp, всегда будет иметь только одну версию библиотеки, известную во время компиляции.

Вопрос

Весьма вероятно, что libfoo будет обновляться в будущем.

1. При создании myapp, можно указать версию минимум из libfoo компоноваться с на основе флага сборки?

2. Я знаю, что имя библиотеки можно указать непосредственно в CLI сборки. Будет ли это вызвано тем, что myapp потребует точно, что версия или более поздние версии lib с той же основной версией все же могут быть связаны с ней (например, libfoo.so.0.2.0)? Я действительно надеюсь, что вам не придется обновлять каждую зависимую версию приложения каждый раз, когда выпускается новая младшая версия.

3. Есть ли более интеллектуальный способ достижения этого агентом-агностиком?

Ссылка

How do you link to a specific version of a shared library in GCC

Answer 1

Вы описываете внешних библиотеки версий, где приложение построено против libfoo.so.0, libfoo.so.1 и т.д. Документации here.

Использование внешнего управления версиями библиотеки требует, чтобы точно такая же версия libfoo.so.x присутствовала во время выполнения.

Это, как правило, не правильный метод на Linux, которая, с помощью магии symbol versioning, позволяет один libfoo.so.Y для обеспечения нескольких несовместимых определений одного и того же символа, и, таким образом, позволяет одной библиотеке служить и старым и новых приложений одновременно.

Кроме того, если вы просто всегда добавляете новые символы и не изменяете существующие символы несовместимым образом, то есть нет причины, чтобы увеличить внешнюю версию. Держите libfoo.so в версии 0, укажите глобальную переменную int foo_version_X_Y; (как и все предыдущие версии: foo_version_1_0, foo_version_1_1 и т. Д.) И попросите двоичный код приложения прочитать переменную, которую он запрашивает. Если приложение требует новый символ foo_version_1_2 и запускается со старой библиотекой, которая предоставляет только foo_version_1_1, приложение не сможет начать с очевидной ошибки.