CentOS 5.2: GLibC-Version zu alt (Libgio-Problem), Upgrade auf welche GLibC-Version

729
Dominique

Ich arbeite an einem CentOS 5.2 System.
Die Anwendung, die ich starten möchte, wird abgelehnt, da ein Verweis libgio-2.0.so.0nicht existiert.

Dies scheint auf die GLibC-Version zurückzuführen zu sein, also hatte ich an ein Upgrade gedacht und da ich sowieso ein Upgrade durchführen muss, warum sollte ich nicht die neueste Version 2.23 nehmen?
Leider scheint GLibC 2.23 CentOS 5.2 nicht zu unterstützen.

Auf der anderen Seite habe ich bereits viele andere Bibliotheken (GCC, GDB, Binutils, Texinfo, MakeInfo, ...) auf aktuelle Versionen aktualisiert, und ein Upgrade auf, sagen wir, GLibC 2.6, beschwert sich darüber, dass diese anderen Bibliotheken sind zu neu.

Anstatt in einem Trial-and-Error-Modus fortzufahren, würde ich gerne wissen, welche Version von GLibC auf einem CentOS 5.2-Computer installiert werden kann.

0

2 Antworten auf die Frage

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

Es hat den Anschein, dass sich meine Bewerbung auf libglass.so bezog, was wiederum vom JFRT.jar-Java-Paket abgerufen wurde. Die Verwendung dieses Pakets ist jedoch für meine Anwendung nicht wesentlich (es wird nur zum Rendern und Anzeigen von HTML-Nachrichten verwendet, was nicht unbedingt erforderlich ist). Daher haben wir uns entschieden, diesen Teil der Anwendung zu entfernen.

Meine Anwendung enthält immer noch Verweise auf JFRT.jar, aber da diese JAR-Datei nur dynamisch geladen wird, können wir die Problemumgehung dafür verwenden (hiermit wird der Nutzen des dynamischen Ladens erneut demonstriert :-))

Verwandte Probleme