Próbuję skompilować mój program, który zwraca ten błąd:
usr/bin/ld: cannot find -l<nameOfTheLibrary>
w moim makefile używam polecenia g++
i linku do mojej biblioteki, która jest symbolicznym linkiem do mojej biblioteki znajdującej się w innym katalogu.
Czy istnieje opcja dodania, aby działała, proszę?
-l
przełącznika (np. Libpthread.so, więc już łączysz się).Odpowiedzi:
Jeśli nazwa Twojej biblioteki to say
libxyz.so
i znajduje się na ścieżce, powiedz:następnie, aby połączyć go z programem:
źródło
Aby dowiedzieć się, czego szuka linker, uruchom go w trybie pełnym.
Na przykład ten problem napotkałem podczas próby kompilacji MySQL z obsługą ZLIB. Podczas kompilacji otrzymałem taki błąd:
Zrobiłem trochę Googl'ingu i ciągle napotykałem różne problemy tego samego rodzaju, w których ludzie mówili, aby upewnić się, że plik .so faktycznie istnieje, a jeśli nie, to utwórz dowiązanie symboliczne do pliku z wersją, na przykład zlib. 1.2.1. Ale kiedy sprawdziłem, Zlib.so DID istnieje. Pomyślałem więc, że to nie może być problem.
Natknąłem się na inny post w Internecie, który sugerował uruchomienie make z LD_DEBUG = all:
Chociaż dostałem TONę danych wyjściowych do debugowania, w rzeczywistości nie było to pomocne. To spowodowało więcej zamieszania niż cokolwiek innego. Więc miałem się poddać.
Potem miałem objawienie. Pomyślałem, żeby sprawdzić tekst pomocy dla polecenia ld:
Na tej podstawie wymyśliłem, jak uruchomić ld w trybie pełnym (wyobraź to sobie):
Oto wynik, który otrzymałem:
Ding, ding, ding ...
Tak więc, aby w końcu to naprawić, abym mógł skompilować MySQL z moją własną wersją ZLIB (zamiast wersji dołączonej):
Voila!
źródło
-Xlinker --verbose
argumenty wiersza poleceń gcc, aby przekazać tę opcję do ld.-Wl,-Bstatic
. Ogranicza to wyszukiwanie tylko do plików .a. Pełna opcja pokazała to wyraźnie. Po usunięciu-Wl,-Bstatic
przeszukiwano również biblioteki współdzielone.-Wl,--verbose
i przekazuje--verbose
linkerowi.-Wl,--verbose
aby przekazać pełny linker.Wydaje się, że nie ma żadnej odpowiedzi, która rozwiązałaby bardzo powszechny problem początkujących polegający na tym, że nie udało się zainstalować wymaganej biblioteki.
Na platformach Debianish, jeśli go
libfoo
brakuje, możesz często zainstalować go za pomocą czegoś takiego-dev
Wersja pakietu jest wymagane w przypadku prac rozwojowych, nawet trywialne prac rozwojowych, takich jak kompilacji kodu źródłowego do linku do biblioteki.Nazwa pakietu czasami wymaga pewnych dekoracji (
libfoo0-dev
?foo-dev
Bezlib
prefiksu? Itp.), Lub możesz po prostu użyć wyszukiwania pakietu swojej dystrybucji, aby dowiedzieć się dokładnie, które pakiety zapewniają konkretny plik.(Jeśli jest ich więcej, musisz dowiedzieć się, jakie są ich różnice. Wybranie najfajniejszego lub najpopularniejszego jest powszechnym skrótem, ale nie do przyjęcia w przypadku poważnych prac programistycznych.)
W przypadku innych architektur (zwłaszcza RPM) obowiązują podobne procedury, choć szczegóły będą inne.
źródło
apt-get install libperl-dev
posortowałem to dla mnie. Dzięki :)yum install openssl-devel
rozwiązanie.Czas kompilacji
Kiedy g ++ mówi
cannot find -l<nameOfTheLibrary>
, to znaczy, że g ++ wyglądał dla plikulib{nameOfTheLibrary}.so
, ale nie mógł go znaleźć w udostępnionej biblioteki wyszukiwania ścieżki, która przez punkty do domyślnych/usr/lib
i/usr/local/lib
gdzieś indziej może.Aby rozwiązać ten problem, należy albo podać plik biblioteki (
lib{nameOfTheLibrary}.so
) w tych ścieżkach wyszukiwania, albo użyć-L
opcji polecenia.-L{path}
mówi g ++ (właściwield
), aby{path}
oprócz plików domyślnych odnalazł pliki bibliotek w ścieżce .Przykład: Zakładając, że masz bibliotekę
/home/taylor/libswift.so
i chcesz połączyć swoją aplikację z tą biblioteką. W takim przypadku powinieneś podać g ++ następujące opcje:Uwaga 1 :
-l
opcja pobiera nazwę biblioteki bezlib
i.so
na początku i na końcu.Uwaga 2 : W niektórych przypadkach po nazwie pliku biblioteki następuje na przykład jego wersja
libswift.so.1.2
. W takich przypadkach g ++ również nie może znaleźć pliku biblioteki. Prostym obejściem tego problemu jest utworzenie dowiązania symbolicznego dolibswift.so.1.2
wywołanialibswift.so
.Środowisko wykonawcze
Po połączeniu aplikacji z biblioteką udostępnioną biblioteka musi być dostępna za każdym razem, gdy uruchomisz aplikację. W czasie wykonywania aplikacja (właściwie dynamiczny linker) szuka bibliotek w
LD_LIBRARY_PATH
. Jest to zmienna środowiskowa, która przechowuje listę ścieżek.Przykład: W przypadku naszego
libswift.so
przykładu, dynamiczny linker nie może znaleźćlibswift.so
wLD_LIBRARY_PATH
(co wskazuje na ścieżki domyślne wyszukiwania). Aby rozwiązać problem, należy dołączyć tę zmienną do ścieżki,libswift.so
w której się znajduje.źródło
.so
pliki/usr/lib
, ale stało się dla mnie interesujące, czyexport
to pomoże. Mimomake
kontynuowania instalacji po dłuższym czasie wystąpił kolejny błąd. Tym razem.so.0
plik nie został znaleziony, ale zarówno plik , jak.so
i.so.0
plik znajdowały się w katalogu, w którym mam pakiet zależny od kompilacji ze źródła. Czy mógłbyś w tym pomóc?Podczas kompilacji z
g++
poprzezmake
określenieLIBRARY_PATH
, jeżeli nie mogą być odpowiednie, aby zmienić Makefile z-L
opcją. Umieściłem swoją dodatkową bibliotekę,/opt/lib
więc:a następnie pobiegł
make
do udanej kompilacji i łączenia.Aby uruchomić program z biblioteką współdzieloną, zdefiniuj:
przed uruchomieniem programu.
źródło
Najpierw musisz znać zasadę nazewnictwa
lxxx
:lc
oznaczalibc.so
,lltdl
znaczylibltdl.so
,lXtst
znaczylibXts.so
.To jest
lib
+lib-name
+.so
Po poznaniu nazwy możemy użyć
locate
ścieżki do tegolxxx.so
pliku.Jeśli nie możesz go znaleźć, musisz go zainstalować
yum
(używam CentOS). Zwykle masz ten plik, ale nie prowadzi on do odpowiedniego miejsca.Połącz go z właściwym miejscem, zwykle jest to
/lib64
lub/usr/lib64
$ sudo ln -s /home/user/anaconda3/lib/libiconv.so /usr/lib64/
Gotowy!
ref: https://i-pogo.blogspot.jp/2010/01/usrbinld-cannot-find-lxxx.html
źródło
locate
działa tylko, jeśli jest zainstalowany i działa regularnie. Prymitywnym obejściem jest uruchomieniefind
na całym dysku, ale oczywiście zajmie to trochę czasu. Jeśli często to robisz, rozważ zainstalowanie,locate
aby obniżyć (interaktywny, ludzki) koszt tej operacji.Podczas kompilacji programu musisz podać ścieżkę do biblioteki; w g ++ użyj opcji -L:
źródło
ccmake
abyMakefile
została utworzona z połączoną flagą? Chcę połączyć moją-lARToolkitPlus
flagę ze ścieżką.Ten błąd może być również spowodowany, jeśli dowiązanie symboliczne jest do biblioteki dynamicznej, .so, ale z przyczyn starszych
-static
pojawia się wśród flag łącza. Jeśli tak, spróbuj go usunąć.źródło
Sprawdź lokalizację swojej biblioteki, na przykład lxxx.so:
Jeśli nie ma go w
/usr/lib
folderze, wpisz:Gotowy.
źródło
Oprócz podanych już odpowiedzi może się zdarzyć, że plik * .so istnieje, ale nie ma odpowiedniej nazwy. Może się zdarzyć, że plik * .so istnieje, ale jest własnością innego użytkownika / root.
Problem 1: Niepoprawna nazwa
Jeśli łączysz plik w ten sposób
-l<nameOfLibrary>
, nazwa pliku biblioteki MUSI mieć formęlib<nameOfLibrary>
Jeśli masz tylko<nameOfLibrary>.so
plik, zmień jego nazwę!Problem 2: Niewłaściwy właściciel
Aby sprawdzić, czy to nie problem - zrób
Jeśli plik należy do użytkownika root lub innego użytkownika, musisz to zrobić
źródło
Okazało się, że biblioteka, do której próbowałem utworzyć łącze, ma niestandardową nazwę (tj. Nie była poprzedzona literą „lib”), więc zalecili użycie takiej komendy do jej skompilowania -
gcc test.c -Iinclude lib/cspice.a -lm
źródło
Oto informacje o Ubuntu mojego laptopa.
Używam locate, aby znaleźć pliki .so dla boost_filesystem i boost_system
Następnie połącz pliki .so do / usr / lib i zmień nazwę na .so
Gotowy! Pakiet R velocyto.R został pomyślnie zainstalowany!
źródło
Napotkałem ten sam komunikat o błędzie.
Zbudowałem
cmocka
jako aso
i próbowałem połączyć go z moim plikiem wykonywalnym. Aleld
zawsze narzeka poniżej:Okazuje się, że po
cmocka
skompilowaniu generowane są 3 pliki :1 i 2 są linkami symboli, a tylko 3 to prawdziwy plik.
Skopiowałem tylko 1 do folderu biblioteki, w którym
ld
nie udało się znaleźć 3.Po skopiowaniu wszystkich 3
ld
działa.źródło