Освобождение программного обеспечения linux – совместимость

Я хочу выпустить библиотеку C ++ для Linux. Верно ли, что (когда никакие другие библиотеки не связаны динамически), только версия glibc решает совместимость с другими дистрибутивами Linux?

Есть ли лучший способ поддерживать большинство дистрибутивов Linux за последние 5 лет, чем создавать несколько виртуальных машин и компилировать их там? Например, будет ли бинарный файл Linux, который был скомпилирован в очень старой системе Linux, запущен в новых версиях Linux?

Ядро API Linux очень стабильно. (Я говорю о системных вызовах, а не API-интерфейсах внутри ядра.) Статически связанный исполняемый файл, созданный с 1997 года или около него (переход на ELF в качестве исполняемого формата), должен работать на любых существующих системах Linux. Тем не менее, статически связанные исполняемые файлы имеют много недостатков: они громоздки, они не могут быть легко обновлены, если ошибки обнаружены в стороннем коде, и они, как правило, живут в своем собственном пузыре, поскольку у них есть проблемы с взаимодействием с некоторыми функциями системы для которых стандартная библиотека предоставляет настраиваемую поддержку (например, DNS, локали, учетные записи пользователей, …).

Для библиотек общим соглашением является то, что изменение первого числа в версии указывает на несовместимое изменение ABI, а остальная часть версии увеличивается на обратно совместимые изменения. Например, если ваша программа связана с версией 2.3, она будет работать с версиями 2.3 или 2.4 библиотеки, но не с 2.2 или 3. Некоторые библиотеки используют разные соглашения. Динамический компоновщик использует сонамер, записанный в библиотеке, чтобы решить, подходит ли его версия.

Стандартной библиотекой на не встроенной Linux является Glibc . Основная версия Glibc была 6 в Linux (так называется libc6) с 1998 года; верхняя основная версия – 2, что объясняет, почему версия libc6 равна 2. MINOR, а не 6. MINOR . В принципе, программы, связанные со старой версией libc6, должны работать с более поздними версиями, хотя это не всегда верно на ранних этапах. Любая программа, связанная с Glibc 2.3 или выше, должна работать с текущими версиями.

Стандартная библиотека C ++, используемая для изменения быстрее, но текущая основная версия (6) работает с 2005 года.

Если вы компилируете программу в более старую систему, она должна работать на более новых системах при условии наличия необходимых версий библиотеки. Возьмите самую старую поддерживаемую версию CentOS (в настоящее время 5) и старейшую [старую] стабильную версию Debian (в настоящее время хриплый, хотя сжатие может по-прежнему соответствовать); если вы создаете двоичный файл, который работает на обоих, он, вероятно, будет работать на всех установках Linux (исключенные встроенные системы и те, в которых работают устаревшие версии, для которых обновления для системы безопасности больше недоступны).

Да, в основном, хотя вам может понадобиться избежать новых возможностей ядра.

Если вы хотите создать переносимую C ++-программу, желательно придерживаться официального стандарта ISO C ++. По мере изменения стандарта вам может потребоваться адаптировать вашу программу, но обычно это не так много работы.

Вы можете попросить g ++ придерживаться более старого стандарта, чтобы ваша программа не компилировалась на компьютере со старой библиотекой. Определяет, как выглядит компилятор.

-D__STRICT_ANSI__ -D_ISOC99_SOURCE=1 -D_ISOC9X_SOURCE=1 

(для С).

Конечно, есть также аппаратная проблема (целевой процессор, включая архитектуру, такую ​​как IA64, и функции процессора, такие как SSE).