CentOS 5.2: слишком старая версия GLibC (проблема libgio), обновление до версии GLibC

Question

Я работаю над системой CentOS 5.2.
Приложение, которое я пытаюсь запустить, отказывается, потому что ссылка на libgio-2.0.so.0 кажется, не существует.

Похоже, это связано с версией GLibC, поэтому я подумал об ее обновлении, и, так как мне все равно нужно обновиться, почему бы не взять самую последнюю версию 2.23?
Ну, к сожалению, GLibC 2.23, похоже, не поддерживает CentOS 5.2.

С другой стороны, я уже обновил многие другие библиотеки (GCC, GDB, binutils, Texinfo, MakeInfo, ...) до последних версий, и обновление до, скажем, GLibC 2.6, жалуется на тот факт, что эти другие библиотеки слишком недавно

Вместо того чтобы продолжать работу в режиме проб и ошибок, я бы хотел узнать, какую версию GLibC самой высокой версии я могу установить на компьютере с CentOS 5.2?

Answer 1

Я работаю над системой CentOS 5.2.

Текущая версия CentOS 5 - 5.11. У вас и нелепо устаревшая система.

libgio-2.0.so.0, кажется, не существует.

На CentOS 6 и новее это обеспечивается пакетом glib2. Пакет glib2 в CentOS 5 этого не обеспечивает. Спасите себя от хлопот и просто обновитесь до CentOS 6 или 7.

Ну, к сожалению, GLibC 2.23, похоже, не поддерживает CentOS 5.2.

Это не то, как работает CentOS. Версии большинства приложений по существу заморожены, и затем они получают исправления безопасности, о которых сообщалось ранее. На этой странице все объясняется. Обновление пакета вне системных пакетов не рекомендуется и часто приводит к серьезной поломке системы.

С другой стороны, я уже обновил многие другие библиотеки (GCC, GDB, binutils, Texinfo, MakeInfo, ...) до последних версий, и обновление до, скажем, GLibC 2.6, жалуется на тот факт, что эти другие библиотеки слишком недавно

Как я уже сказал, сильно сломанная система.

Answer 2

Похоже, что мое приложение ссылалось на libglass.so, который, в свою очередь, был вызван Java-пакетом JFRT.jar. Однако использование этого пакета не является обязательным для моего приложения (оно используется только для рендеринга и отображения HTML-сообщений, что не является обязательным), поэтому мы решили удалить эту часть приложения.

Мое приложение все еще содержит ссылки на JFRT.jar, но так как этот jar-файл загружается только динамически, мы можем использовать обходной путь для этого (этим снова демонстрируется полезность динамической загрузки :-))