Как именно система может сломаться при обновлении glibc?
Предположим, у меня есть программа, основанная на более новой версии glibc, которая недоступна в системе через пакеты. И это дает:
version `GLIBC_2.xxx' not found
Одним из решений является статическая компиляция двоичного файла с помощью glibc.
Другое решение, которое многие люди считают "небезопасным", ставит новые libc.so.6 вместо того, который поставляется операционной системой.
Как именно это второе решение небезопасно или плохая идея, при условии, что libc.so.6 включает в себя предыдущие конечные точки ABI?
Например, если я бегу strings /usr/lib/libc.so.6 | grep --perl-regexp "^GLIBC_" Я вижу много таких версий ABI, как:
...
GLIBC_2.10
GLIBC_2.11
GLIBC_2.12
GLIBC_2.13
GLIBC_2.14
GLIBC_2.15
GLIBC_2.16
GLIBC_2.17
...
Так что, если я переписываю с более новым libc.so.6 с дополнительными версиями glibc ABI внутри, как это ломает старые приложения или приводит к поломке системы?
Или нет...?:)
2 ответа
В целом, двоичные файлы, скомпилированные для более старой версии glibc, будут нормально работать в системе с более новым glibc, поскольку glibc обратно совместим и обрабатывает изменения в своем двоичном интерфейсе приложения (ABI). Это достигается этим волшебством с помощью управления версиями символов, где в основном к каждому символу прикрепляется тег, указывающий его версию glibc.
В случае изменения семантики в вызовах функций, glibc будет включать две версии: одну для старой семантики и другую для новой семантики, поэтому каждая функция помечается своей версией. Компоновщик будет рассматривать обе версии как две разные функции.
Этот сложный механизм необходим, поскольку glibc - не один файл, а состоит из множества частей (более 200 общих библиотек).
Обратная совместимость версий glibc постоянно отслеживается. Вы можете ознакомиться с отчетом Лаборатории ABI для обзора изменений API/ABI для glibc. Отчет генерируется средствами abi-Compliance Checker и abi-tracker.
На ваш вопрос:
Так что, если я перезаписываю более новым libc.so.6 дополнительными версиями glibc ABI внутри, как это ломает старые приложения или приводит к поломке системы? Или нет...?
Совместимость с Glibc небезопасна, но я считаю, что вам придется вернуться к продуктам, скомпилированным на довольно старых версиях Linux, чтобы сломать ее. Я бы также сказал, что продукты могут ломаться не только из-за glibc при работе на версиях Linux, отличных от того, где они были скомпилированы.
Лучший ответ, который я могу дать:
"Это не должно ничего ломать, и есть отличный шанс, что это не будет".
Для получения дополнительной информации см.:
Прямой ответ на ваш вопрос заключается в том, что если вы используете более новую (не обязательно поддерживаемую) версию. У вас нет гарантии, что функция не была удалена или изменена таким образом, что другие (более старые) приложения смогут справиться с этими изменениями. Фактически, они не смогут справиться с вашей новой версией, если ваша новая версия не предоставляет "прокладки" для поддержки так называемых "устаревших" функций, которые были удалены или несовместимо изменены.
Итак, если вы надеетесь на успех в своих начинаниях, вам нужно изучить Changelog(s) после "поддерживаемой" версии Glibc. Чтобы безопасно определить, что изменилось.:)