/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!

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.


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.


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.


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


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!


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


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.


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

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.


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.


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



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.


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.


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.


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.


0

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

g++ test.cpp -static-libstdc++

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.


Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.