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

645
Dominique

Я работаю над системой 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?

0

2 ответа на вопрос

0
carlwgeorge

I'm working on a CentOS 5.2 system.

The current version of CentOS 5 is 5.11. You have and absurdly out of date system.

libgio-2.0.so.0 seems not to exist.

On CentOS 6 and newer, that is provided by the glib2 package. The glib2 package in CentOS 5 does not provide that. Save yourself the hassle and just upgrade to CentOS 6 or 7.

Well, unfortunately, GLibC 2.23 seems not to support CentOS 5.2.

That's not how CentOS works. The versions of most applications are essentially frozen, and then they receive backported security fixes. This page explains it all. Upgrading package outside of the system packages is not recommended and will often result in a severely broken system.

On the other hand, I have already upgraded much other libraries (GCC,GDB, binutils, Texinfo, MakeInfo, ...) to recent versions, and an upgrade to, let's say GLibC 2.6, is complaining about the fact that those other libraries are too recent.

Like I said, a severely broken system.

0
Dominique

It seems that my application was referring to libglass.so, which was in its turn called upon by JFRT.jar java package. The usage of this package, however, is not essential to my application (it's only used for rendering and displaying HTML messages, which is not essential), so we have decided to remove that part of the application.

My application still contains references to JFRT.jar, but as that jar-file is only dynamically loaded, we can use workaround for this (by this the usefulness of dynamic loading is again demonstrated :-) )

Похожие вопросы