/usr/lib/libstdc++.so.6: versão `GLIBCXX_3.4.15 'não encontrada

135

Como posso obter o GLIBCXX_3.4.15 no Ubuntu? Não consigo executar alguns programas que estou compilando.

Quando eu faço:

strings /usr/lib/libstdc++.so.6 | grep GLIBC

Eu recebo:

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_3.4.14
GLIBC_2.2.5
GLIBC_2.3
GLIBC_2.4
GLIBC_2.3.4
GLIBC_2.3.2
GLIBCXX_FORCE_NEW
GLIBCXX_DEBUG_MESSAGE_LENGTH

Obrigado por qualquer ajuda!

c++ gcc libstdc++ Chris
fonte

Respostas:

81

Estou compilando o gcc 4.6 da fonte e, aparentemente,

sudo make install

não peguei este. Eu procurei e encontrei

gcc/trunk/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6.0.15

Copiei-o para / usr / lib e redirecionei libstdc ++. So.6 para apontar para o novo e agora tudo funciona.

Chris
fonte
1
Eu tenho o mesmo problema, e este post / resposta é exatamente o que estou procurando. Muito obrigado!
Yo #
1
Isso funciona com o gcc 4.6.2 também, exceto pelo libstdc ++. So.6.0.16. Obrigado!
Venesectrix
2
O meu é o gcc 4.7 e o libstdc ++. So.6.0.17. Teve o mesmo problema, corrigido com esta solução. Parabéns.
Ricbit
1
Sim existe. Uma apt-getsolução baseada para este problema é descrita aqui: superuser.com/questions/310809/...
aroth
4
@roosevelt: não é um problema com o sistema operacional, é um problema com os usuários que instalam o software e não usam o vinculador corretamente. É um FAQ: gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.how_to_set_paths
Jonathan Wakely
54

Eu estive evitando esse problema no passado, simplesmente vinculando libstdc ++ estaticamente com este parâmetro enviado para g ++ ao vincular meu executável:

-static-libstdc++

Se o vínculo estatístico na biblioteca for uma opção, esta provavelmente é a solução mais rápida.

Martin G
fonte
2
Muito obrigado, tentei todas as outras soluções sugeridas no SO e nada funcionou além desta.
Itamar Katz
1
Obrigado pela sua solução, isso me ajuda muito!
Brightshine
O problema é que a biblioteca não pode ser encontrada, não que você deve vincular estaticamente. Veja a resposta de @Hobo.
Dan Mergens 26/11/19
45

Eu estava tentando fazer o clang funcionar (que também requer 6.0.15) e, enquanto bisbilhotava, descobri que ele estava instalado em /usr/local/lib/libstdc++.so.6.0.15. Ele foi instalado lá quando eu instalei o grafite (uma versão experimental do gcc).

Se você precisar acessar as bibliotecas nesse local, será necessário definir LD_LIBRARY_PATHcomo:

export LD_LIBRARY_PATH=/usr/local/lib:/usr/lib:/usr/local/lib64:/usr/lib64

Eu era capaz de fazer clang para trabalhar depois de fazer isso. Espero que seja útil para alguém.

Vagabundo
fonte
Eu estava trabalhando em um destino incorporado e recebo o mesmo problema, sua solução parece não funcionar no meu caso. De fato, a maior parte do binário no destino usa a biblioteca c padrão em / lib, portanto a alteração LD_LIBRARY_PATHos afetará. todos eles vão link para a nova biblioteca, No final, a maioria dos binários não estão funcionando: tais como ls grep, ....: I'am recebendo:ls: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
Mouin
14

Encontro esse problema ao tentar usar o matlab eng para chamar funções m do código c. o que ocorre com o comandomex -f .. ..

Minha solução: 

strings /usr/lib/i386-<tab>/libstdc++.so.6 | grep GLIBC

Eu achei que inclui 3.4.15

então meu sistema tem as mais recentes bibliotecas.

o problema vem do próprio matlab, ele chama seu próprio libstdc ++. so.6 {MATLAB}/bin

portanto, substitua-o pela lib do sistema atualizada.

Cheng Chang
fonte
Isto parece também trabalho para mim em Matlab 2013b x64 em Xubuntu 13,04 x64
Marcin
Muito obrigado. Eu apenas tive que criar um novo link simbólico para o arquivo no {MATLAB}/binarquivo /usr/lib/e, em seguida, reiniciar o matlab. Isso funciona no Matlab 2010b no Fedora 14 x64.
Wok
2

Eu tenho o mesmo erro. É assim que funcionou para mim:

  • limpou o projeto sob o gcc atualmente instalado
  • recompilou

Funcionou perfeitamente!

iueae
fonte
2

Para esse erro, copiei o libstdc ++. So.6.0.17 mais recente de outro servidor, removi o link flexível e o recriei.

1. Copie o libstdc ++. So.6.0.15 ou mais recente de outro servidor para o sistema afetado.
No meu caso, o SUSE linux 11 SP3 possuía as últimas.
2. rm libstdc ++. So.6
3. ln -s libstdc ++. So.6.0.17 libstdc ++. So.6 (no diretório / usr / lib64).

nJoy

crazyLinux
fonte
2

Acabei de enfrentar um problema semelhante ao criar a versão LLVM 3.7. primeiro verifique se você instalou a biblioteca necessária em seu sistema:

$locate libstdc++.so.6.*

Em seguida, adicione o local encontrado à sua variável de ambiente $ LD_LIBRARY_PATH.

Arsen
fonte
2
Isso só funciona, se você tem um libstdc ++ so.6 * lib com GLIBCXX_3.4.15 apoio..
warunapww
2

Às vezes, você não controla a máquina de destino (por exemplo, sua biblioteca precisa ser executada em um sistema corporativo bloqueado). Nesse caso, você precisará recompilar seu código usando a versão do GCC que corresponde à versão GLIBCXX. Nesse caso, você pode fazer o seguinte:

  1. Procure a versão mais recente do GLIBCXX suportada pela máquina de destino: strings /usr/lib/libstdc++.so.6 | grep GLIBC... Digamos que a versão seja 3.4.19.
  2. Use https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html para encontrar a versão correspondente do GCC. No nosso caso, este é [4.8.3, 4.9.0).
Gili
fonte
1

gcc versão 4.8.1, o erro parece:

/ root / bllvm / build / Release + Asserts / bin / llvm-tblgen: /usr/lib64/libstdc++.so.6: versão `GLIBCXX_3.4.15 'não encontrada (exigido por / root / bllvm / build / Release + Asserts / bin / llvm-tblgen)

Encontrei o libstdc ++. So.6.0.18 no local em que eu cumpri o gcc 4.8.1

Então eu faço assim

cp ~/objdir/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6.0.18 /usr/lib64/

rm /usr/lib64/libstdc++.so.6

ln -s libstdc++.so.6.0.18 libstdc++.so.6

problema resolvido.

Favoorr
fonte
1

Eu os extraí de um RPM ( RPM para libstdc ++ ) e depois:

export LD_LIBRARY_PATH=.

Definir o sistema para procurar as bibliotecas no diretório atual. Então apenas executei meu programa. Mas, no meu caso, recebi um único executável de que precisava, não foi uma mudança no sistema.

prmottajr
fonte
0

Eu tive um problema semelhante e o resolvi vinculando estaticamente libstdc++ao programa que estava compilando, assim:

$ LIBS=-lstdc++ ./configure ... etc.

em vez do habitual

$ ./configure ... etc.

Pode haver problemas com esta solução relacionados ao carregamento de bibliotecas compartilhadas em tempo de execução, mas eu não examinei o problema profundamente o suficiente para comentar.

Evgeni Sergeev
fonte
0

Eu tive o mesmo problema porque mudei o usuário de mim para outra pessoa:

su

Por alguma razão, depois da compilação normal, não consegui executá-la (a mesma mensagem de erro). O ssh diretamente para a outra conta de usuário funciona.

Olá Mundo
fonte
Isso realmente não responde à pergunta. Se você tiver uma pergunta diferente, faça-a clicando em Fazer pergunta . Você também pode adicionar uma recompensa para chamar mais atenção para esta pergunta.
ravron
Não, porque eu tive exatamente o mesmo problema. Foi causado pela alteração do usuário. Também poderia ter acontecido com outra pessoa, digamos, mudando para raiz.
HelloWorld 02/04
Meu erro! Fui jogado pela primeira linha, que parecia que você também tinha o problema. Continue!
ravron
Eu também usei o Ubuntu e também tentei compilar programas e também recebi a mesma mensagem de erro da pergunta. Meu erro foi que eu estava fazendo isso em outra conta de usuário usando o comando su. Acho que isso responde à pergunta porque aborda o porquê e o problema. Certamente é uma possibilidade.
HelloWorld
E um usuário tinha LD_LIBRARY_PATH definido para encontrar a lib mais recente, mas não o outro usuário? Isso parece um pouco rebuscado no contexto específico dessa questão.
Marc Glisse
0

Eu tinha várias versões do compilador gcc instaladas e precisava usar uma versão mais recente que a instalação padrão. Como não sou administrador de sistemas de nossos sistemas Linux, não posso simplesmente alterar / usr / lib ou muitas das outras sugestões acima. Eu estava enfrentando esse problema e, eventualmente, o localizei para definir meu caminho para o diretório da biblioteca de 32 bits em vez do diretório da biblioteca de 64 bits (lib64). Como as bibliotecas no diretório de 32 bits eram incompatíveis, o sistema padronizou a versão mais antiga que estava desatualizada.

O uso de -L no caminho que eu estava referenciando deu avisos sobre "pular a libstdc ++ incompatível. Portanto, ao procurar -lstdc ++". Essa foi a dica que finalmente me ajudou a resolver o problema.

Cathy
fonte
0

A mesma coisa com a versão gcc 4.8.1 (GCC)e libstdc++.so.6.0.18. Tive que copiá-lo aqui /usr/lib/x86_64-linux-gnuna minha caixa do ubuntu.

ervinbosenbacher
fonte
0

No meu caso, LD_LIBRARY_PATH tinha / usr / lib64 primeiro antes de / usr / local / lib64. (Eu estava construindo o llvm 3.9).
O novo compilador gcc que eu instalei para compilar o llvm 3.9 tinha bibliotecas usando as bibliotecas GLIBCXX mais recentes em / usr / local / lib64. Portanto, corrigi LD_LIBRARY_PATH para o vinculador ver primeiro / usr / local / lib64.
Isso resolveu esse problema.

Chan Kim
fonte
0

Eu apenas usei -static-libstdc ++ durante a construção. com isso, eu posso executar o a.out

g++ test.cpp -static-libstdc++
Suresh
fonte
0

Para fins de teste:

Na máquina original, localize a biblioteca, copie para o mesmo diretório que o executável:

$ ldconfig -p | grep libstdc
        libstdc++.so.6 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
        libstdc++.so.6 (libc6) => /usr/lib32/libstdc++.so.6
$ cp /usr/lib/x86_64-linux-gnu/libstdc++.so.6 .

Em seguida, copie esta mesma biblioteca para a máquina de destino e execute o executável:

LD_LIBRARY_PATH=. ./myexecutable

Nota: o comando acima é temporário; não é uma mudança em todo o sistema.

Contango
fonte