/usr/lib/libstdc++.so.6: nie znaleziono wersji `` GLIBCXX_3.4.15 ''

135

Jak mogę uzyskać GLIBCXX_3.4.15 w Ubuntu? Nie mogę uruchomić niektórych programów, które kompiluję.

Kiedy robię:

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

Dostaję:

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

Dzięki za pomoc!

Chris
źródło

Odpowiedzi:

81

Najwyraźniej kompiluję gcc 4.6 ze źródeł

sudo make install 

nie złapałem tego. Rozejrzałem się i znalazłem

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

Skopiowałem go do / usr / lib i przekierowałem libstdc ++. So.6, aby wskazywał na nowy, i teraz wszystko działa.

Chris
źródło
1
Mam ten sam problem, a ten post / odpowiedź jest dokładnie tym, czego szukam. Wielkie dzięki!
yoco
1
Działa to również z gcc 4.6.2, z wyjątkiem tego, że jest to libstdc ++. So.6.0.16. Dzięki!
Venesectrix
2
Moje to gcc 4.7 i libstdc ++. So.6.0.17. Miałem ten sam problem, rozwiązany za pomocą tego rozwiązania. Sława.
Ricbit,
1
Tak jest. apt-getOparty Rozwiązaniem tego problemu jest opisane tutaj: superuser.com/questions/310809/...
aroth
4
@roosevelt: to nie jest problem z systemem operacyjnym, to problem z tym, że użytkownicy sami instalują oprogramowanie, a następnie nie używają poprawnie konsolidatora. To często zadawane pytania: gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.how_to_set_paths
Jonathan
54

W przeszłości unikałem tego problemu, po prostu łącząc libstdc ++ statycznie z tym parametrem wysyłanym do g ++ podczas łączenia mojego pliku wykonywalnego:

-static-libstdc++

Jeśli statyczne linkowanie w bibliotece jest opcją, jest to prawdopodobnie najszybsze obejście.

Martin G.
źródło
2
Wielkie dzięki, wypróbowałem każde inne rozwiązanie sugerowane na SO i nic nie działało poza tym.
Itamar Katz
1
Dzięki za rozwiązanie, bardzo mi to pomaga!
Brightshine
Problem polega na tym, że nie można znaleźć biblioteki, a nie to, że należy łączyć statycznie. Zobacz odpowiedź od @Hobo.
Dan Mergens
45

Próbowałem uruchomić clang (który również wymaga wersji 6.0.15), a podczas szperania w pobliżu stwierdziłem, że jest zainstalowany w /usr/local/lib/libstdc++.so.6.0.15. Zainstalował się tam, kiedy zainstalowałem grafit (eksperymentalna wersja gcc).

Jeśli potrzebujesz dostępu do bibliotek w tej lokalizacji, musisz zdefiniować LD_LIBRARY_PATHjako:

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

Po wykonaniu tej czynności byłem w stanie zabrać się do pracy. Mam nadzieję, że to komuś pomoże.

Włóczęga
źródło
Pracowałem nad osadzonym celem i mam ten sam problem, twoje rozwiązanie wydaje się nie działać w moim przypadku. W rzeczywistości większość plików binarnych w miejscu docelowym używa domyślnej biblioteki c w / lib, więc zmiana LD_LIBRARY_PATHbędzie miała na nie wpływ. wszystkie będą linkować do nowej biblioteki, W końcu większość plików binarnych nie działa: na przykład ls grep...: Otrzymuję:ls: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
Mouin
14

Napotykam ten problem, gdy próbuję użyć języka Matlab do wywołania funkcji m z kodu C. co następuje na poleceniemex -f .. ..

Moje rozwiązanie:

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

Okazało się, że zawiera 3.4.15

więc mój system ma najnowsze biblioteki.

problem pochodzi z samego Matlaba, wywołuje własne libstdc ++. so.6 from {MATLAB}/bin

więc po prostu zastąp go zaktualizowaną biblioteką systemową.

Cheng Chang
źródło
Wydaje się, że działa to również dla mnie w Matlab 2013b x64 na Xubuntu 13.04 x64
Marcin
Wielkie dzięki. Po prostu musiałem utworzyć nowe dowiązanie symboliczne do pliku w {MATLAB}/binpliku w /usr/lib/, a następnie ponownie uruchomić matlab. Działa to w Matlab 2010b w Fedorze 14 x64.
Wok
2

Mam ten sam błąd. Tak to działało u mnie:

  • wyczyściłem projekt pod aktualnie zainstalowanym gcc
  • ponownie go skompilował

Działało idealnie!

iueae
źródło
2

W przypadku tego błędu skopiowałem najnowszą wersję libstdc ++. So.6.0.17 z innego serwera, usunąłem link miękki i odtworzyłem go.

1. Skopiuj plik libstdc ++. So.6.0.15 lub nowszy z innego serwera do systemu, którego dotyczy luka.
W moim przypadku SUSE linux 11 SP3 miał najnowsze.
2. rm libstdc ++. So.6
3. ln -s libstdc ++. So.6.0.17 libstdc ++. So.6 (w katalogu / usr / lib64).

nJoy

crazyLinux
źródło
2

Właśnie miałem podobny problem z budowaniem wersji LLVM 3.7. najpierw sprawdź, czy zainstalowałeś wymaganą bibliotekę w swoim systemie:

$locate libstdc++.so.6.*

Następnie dodaj znalezioną lokalizację do zmiennej środowiskowej $ LD_LIBRARY_PATH.

Arsen
źródło
2
Działa to tylko wtedy, gdy masz bibliotekę libstdc ++. So.6. * Lib z obsługą
GLIBCXX_3.4.15
2

Czasami nie kontrolujesz maszyny docelowej (np. Twoja biblioteka musi działać w zablokowanym systemie przedsiębiorstwa). W takim przypadku będziesz musiał ponownie skompilować swój kod przy użyciu wersji GCC, która odpowiada ich wersji GLIBCXX. W takim przypadku możesz wykonać następujące czynności:

  1. Wyszukaj najnowszą wersję GLIBCXX obsługiwaną przez maszynę docelową: strings /usr/lib/libstdc++.so.6 | grep GLIBC... Powiedz, że wersja to 3.4.19.
  2. Użyj https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html, aby znaleźć odpowiednią wersję GCC. W naszym przypadku tak jest [4.8.3, 4.9.0).
Gili
źródło
1

gcc w wersji 4.8.1, wygląda na to, że błąd:

/ root / bllvm / build / Release + Asserts / bin / llvm-tblgen: /usr/lib64/libstdc++.so.6: nie znaleziono wersji `GLIBCXX_3.4.15 '(wymagane przez / root / bllvm / build / Release + Asserts / bin / llvm-tblgen)

Znalazłem libstdc ++. So.6.0.18 w miejscu, w którym przestrzegałem gcc 4.8.1

Więc to lubię

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

problem rozwiązany.

Favoorr
źródło
1

Wyodrębniłem je z RPM ( RPM dla libstdc ++ ), a następnie:

export LD_LIBRARY_PATH=.

Aby ustawić system tak, aby wyszukiwał biblioteki w bieżącym katalogu. Wtedy właśnie wykonałem mój program. Ale w moim przypadku otrzymałem jeden plik wykonywalny, którego potrzebowałem, nie była to zmiana obejmująca cały system.

prmottajr
źródło
0

Miałem podobny problem i rozwiązałem go, łącząc się statycznie libstdc++z programem, który kompilowałem, na przykład:

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

zamiast zwykłego

$ ./configure ... etc.

Z tym rozwiązaniem mogą wystąpić problemy związane z ładowaniem bibliotek współdzielonych w czasie wykonywania, ale nie zagłębiłem się w ten problem na tyle szczegółowo, aby go skomentować.

Evgeni Sergeev
źródło
0

Miałem ten sam problem, ponieważ zmieniłem użytkownika ze siebie na kogoś innego:

su

Z jakiegoś powodu po wykonaniu normalnej kompilacji nie byłem w stanie go wykonać (ten sam komunikat o błędzie). Działa bezpośrednio ssh na inne konto użytkownika.

Witaj świecie
źródło
To naprawdę nie odpowiada na pytanie. Jeśli masz inne pytanie, możesz je zadać, klikając Zadaj pytanie . Możesz także dodać nagrodę, aby zwrócić większą uwagę na to pytanie.
ravron
Nie, to robi, ponieważ miałem dokładnie ten sam problem. Było to spowodowane zmianą użytkownika. Mogło się to również przydarzyć komuś innemu, powiedzmy, że przeszedł na roota.
HelloWorld
Mój błąd! Rzuciła mnie pierwsza linia, która wyglądała tak, jakbyś miał problem. Kontynuować!
ravron
Użyłem również Ubuntu, a także próbowałem skompilować programy i otrzymałem ten sam komunikat o błędzie, co w pytaniu. Mój błąd polegał na tym, że robiłem to na innym koncie użytkownika za pomocą polecenia su. Myślę, że to odpowiada na pytanie, ponieważ wyjaśnia, dlaczego i jak o problemie. Na pewno jest taka możliwość.
HelloWorld
Jeden użytkownik miał ustawioną LD_LIBRARY_PATH, aby znaleźć nowszą bibliotekę, ale nie drugi użytkownik? Wydaje się to nieco naciągane w konkretnym kontekście tego pytania.
Marc Glisse
0

Miałem zainstalowanych wiele wersji kompilatora gcc i potrzebowałem użyć nowszej wersji niż domyślna instalacja. Ponieważ nie jestem administratorem systemu dla naszych systemów Linux, nie mogę po prostu zmienić / usr / lib lub wielu innych sugestii powyżej. Napotkałem ten problem i ostatecznie wyśledziłem go do ustawienia mojej ścieżki do katalogu biblioteki 32-bitowej zamiast katalogu biblioteki 64-bitowej (lib64). Ponieważ biblioteki w katalogu 32-bitowym były niekompatybilne, system domyślnie ustawił starszą wersję, która była nieaktualna.

Użycie -L do ścieżki, do której się odnosiłem, dało ostrzeżenia o „pomijaniu niekompatybilnego libstdc ++. Więc podczas wyszukiwania -lstdc ++”. To była wskazówka, która pomogła mi ostatecznie rozwiązać problem.

Cathy
źródło
0

To samo z wersją gcc 4.8.1 (GCC)i libstdc++.so.6.0.18. Musiałem go skopiować tutaj /usr/lib/x86_64-linux-gnuna moje pudełko ubuntu.

ervinbosenbacher
źródło
0

W moim przypadku LD_LIBRARY_PATH miał / usr / lib64 najpierw przed / usr / local / lib64. (Budowałem llvm 3.9).
Nowy kompilator gcc, który zainstalowałem, aby skompilować llvm 3.9, miał biblioteki korzystające z nowszych bibliotek GLIBCXX w / usr / local / lib64. Naprawiłem więc LD_LIBRARY_PATH, aby linker widział najpierw / usr / local / lib64.
To rozwiązało ten problem.

Chan Kim
źródło
0

Właśnie użyłem -static-libstdc ++ podczas budowania. w / to mogę uruchomić a.out

g++ test.cpp -static-libstdc++
Jasne
źródło
0

Do celów testowych:

Na oryginalnym komputerze znajdź bibliotekę i skopiuj ją do tego samego katalogu, co plik wykonywalny:

$ 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 .

Następnie skopiuj tę samą bibliotekę na maszynę docelową i uruchom plik wykonywalny:

LD_LIBRARY_PATH=. ./myexecutable

Uwaga: powyższe polecenie jest tymczasowe; nie jest to zmiana dotycząca całego systemu.

Contango
źródło