CentOS 5.2: versão do GLibC muito antiga (libgio), upgrade para qual versão do GLibC

Question

Estou trabalhando em um sistema CentOS 5.2.
O aplicativo que estou tentando iniciar recusa porque uma referência a libgio-2.0.so.0 parece não existir.

Isto parece ser devido à versão GLibC, então eu pensei em atualizar isso, e como eu preciso atualizar de qualquer maneira, por que não pegar a versão mais recente 2.23?
Bem, infelizmente, o GLibC 2.23 parece não suportar o CentOS 5.2.

Por outro lado, eu já atualizei muitas outras bibliotecas (GCC, GDB, binutils, Texinfo, MakeInfo, ...) para versões recentes, e uma atualização para, digamos GLibC 2.6, está reclamando sobre o fato de que essas outras bibliotecas são muito recentes.

Em vez de continuar em um modo de tentativa e erro, gostaria de saber qual é a versão mais alta do GLibC que posso instalar em uma máquina CentOS 5.2?

    

Answer 1

I'm working on a CentOS 5.2 system.

A versão atual do CentOS 5 é 5.11. Você tem um sistema absurdamente desatualizado.

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

No CentOS 6 e mais recente, isso é fornecido pelo pacote glib2. O pacote glib2 no CentOS 5 não fornece isso. Salve-se do incômodo e atualize para o CentOS 6 ou 7.

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

Não é assim que o CentOS funciona. As versões da maioria dos aplicativos são essencialmente congeladas e, em seguida, recebem correções de segurança portadas. Esta página explica tudo. A atualização do pacote fora dos pacotes do sistema não é recomendada e geralmente resultará em um sistema severamente quebrado.

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.

Como eu disse, um sistema severamente quebrado.

    

Answer 2

Parece que meu aplicativo estava se referindo ao libglass.so, que por sua vez era chamado pelo pacote java JFRT.jar. O uso deste pacote, no entanto, não é essencial para o meu aplicativo (ele é usado apenas para renderizar e exibir mensagens HTML, o que não é essencial), por isso decidimos remover essa parte do aplicativo.

Meu aplicativo ainda contém referências a JFRT.jar, mas como esse arquivo jar é carregado apenas dinamicamente, podemos usar uma solução alternativa para isso (por isso, a utilidade do carregamento dinâmico é novamente demonstrada :-))