GLIBCXX 3.4.15 no Centos 6

Question

Eu preciso instalar o GLIBCXX 3.4.15 na minha versão do Centos 6 (para rodar um servidor para um jogo no Steam). Eu pesquisei por aí e tive vários sites onde eles instalaram programas onde o erro apareceu, onde ele disse que 3.4.15 era necessário ( LoadLibrary ERROR: /usr/lib/libstdc++.so.6: version 'GLIBCXX_3.4.15' not found ), mas eles usaram apenas uma maneira de contorná-lo / não instalá-lo. Quando eu fiz strings /usr/lib/libstdc++.so.6 | grep GLIBCXX , esta foi a saída:

GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_FORCE_NEW
GLIBCXX_DEBUG_MESSAGE_LENGTH

Então, como eu instalaria diretamente o GLIBCXX 3.4.15 no Centos 6?

    

Answer 1

Eu consideraria isso um hack, mas usei-o em mais ocasiões do que gostaria de admitir para resolver problemas de compatibilidade com o GLIBC, como o que você está encontrando.

O hack envolve a criação de um link em /usr/lib , que inclui o nome da biblioteca que uma determinada ferramenta deseja. O link aponta para o nome alternativo da biblioteca.

Exemplo

Digamos que eu queira criar um link para libstdc++.so.6 .

$ ls -l /usr/lib | grep libstdc++.so
lrwxrwxrwx.  1 root root       19 Dec 18  2010 libstdc++.so.6 -> libstdc++.so.6.0.14
-rwxr-xr-x   1 root root   950428 Sep 24  2010 libstdc++.so.6.0.14

Funciona assim:

$ ln -s libstdc++.so.6 libstdc++.so.6.0.15

Verificando os resultados:

$ ls -l /usr/lib | grep libstdc++.so
lrwxrwxrwx.  1 root root       19 Dec 18  2010 libstdc++.so.6 -> libstdc++.so.6.0.14
lrwxrwxrwx.  1 root root       19 Dec 18  2010 libstdc++.so.6.0.15 -> libstdc++.so.6.0.14
-rwxr-xr-x   1 root root   950428 Sep 24  2010 libstdc++.so.6.0.14

Mas não tenho certeza se esse método funcionará, já que a biblioteca ainda estará perdendo a string da versão, GLIBCXX_3.4.15 .

Se o hack for malsucedido, você provavelmente terá que morder o marcador e instalar o GLIBC em um diretório alternativo e, em seguida, substituir LD_LIBRARY_PATH ou LD_PRELOAD para que a execução de apenas vapor veja a biblioteca modificada.

Exemplo

$ LD_PRELOAD='mylibc.so anotherlib.so' program

Detalhes sobre como fazer isso são abordados um pouco mais aqui neste SO Q & A: Várias bibliotecas glibc em um único host .

    

Answer 2

Basicamente, a versão do pacote RPM da libstdc ++ enviada pelo CentOS (4.4.7) não é recente o suficiente para a sua aplicação. O CentOS oferece estabilidade a longo prazo em vez das versões mais recentes e melhores, o que não é completamente inesperado.

O Fedora normalmente está um pouco à frente e pode executar seu servidor sem problemas.

Como alternativa, você pode criar uma versão mais nova do libstdc ++ a partir de uma fonte mais atual. Gostaria de começar com o arquivo CentOS SPEC no gcc SRPM, a última versão do gcc.gnu.org e refazê-los para criar meus próprios RPMs.

Atualizações de bibliotecas C foram no passado uma boa maneira de quebrar um sistema de formas inesperadas ...

    

Answer 3

Eu tive o mesmo problema com o módulo grpc (importado pelo google-cloud) para o nodejs v6.9.2. Esta solução funcionou para mim: (de link )

tar xzf gcc-4.6.2.tar.gz
cd gcc-4.6.2
./contrib/download_prerequisites
cd ..
mkdir objdir
cd objdir
$PWD/../gcc-4.6.2/configure --prefix=/opt/gcc-4.6.2
make
make install