ZooOo
Ich versuche mein Programm zu kompilieren und es gibt diesen Fehler zurück:
usr/bin/ld: cannot find -l<nameOfTheLibrary>
In meinem Makefile verwende ich den Befehl g++ und Link zu meiner Bibliothek, was ein symbolischer Link zu meiner Bibliothek ist, die sich in einem anderen Verzeichnis befindet.
Gibt es eine Option zum Hinzufügen, damit es funktioniert?
dcarrith
Um herauszufinden, wonach der Linker sucht, führen Sie ihn im ausführlichen Modus aus.
Ich bin beispielsweise auf dieses Problem gestoßen, als ich versucht habe, MySQL mit ZLIB-Unterstützung zu kompilieren. Ich habe während der Kompilierung eine Fehlermeldung wie diese erhalten:
/usr/bin/ld: cannot find -lzlib
Ich habe etwas gegoogelt und bin immer wieder auf verschiedene Probleme der gleichen Art gestoßen, bei denen die Leute sagten, sie sollten sicherstellen, dass die .so-Datei tatsächlich existiert, und wenn dies nicht der Fall ist, erstellen Sie einen Symlink zu der versionierten Datei, z. B. zlib. also.1.2.8. Aber als ich nachgesehen habe, existierte zlib.so. Also, dachte ich, das kann doch nicht das Problem sein.
Ich bin im Internet auf einen anderen Beitrag gestoßen, der vorschlug, make mit LD_DEBUG=all auszuführen:
LD_DEBUG=all make
Obwohl ich eine Menge Debugging-Ausgaben erhalten habe, war es nicht wirklich hilfreich. Es fügte mehr Verwirrung hinzu als alles andere. Also war ich kurz davor aufzugeben.
Dann hatte ich eine Offenbarung. Ich dachte, ich sollte den Hilfetext für den Befehl ld überprüfen:
ld --help
Daraus habe ich herausgefunden, wie man ld im ausführlichen Modus ausführt (stellen Sie sich das vor):
ld -lzlib --verbose
Dies ist die Ausgabe, die ich bekommen habe:
==================================================
attempt to open /usr/x86_64-linux-gnu/lib64/libzlib.so failed
attempt to open /usr/x86_64-linux-gnu/lib64/libzlib.a failed
attempt to open /usr/local/lib64/libzlib.so failed
attempt to open /usr/local/lib64/libzlib.a failed
attempt to open /lib64/libzlib.so failed
attempt to open /lib64/libzlib.a failed
attempt to open /usr/lib64/libzlib.so failed
attempt to open /usr/lib64/libzlib.a failed
attempt to open /usr/x86_64-linux-gnu/lib/libzlib.so failed
attempt to open /usr/x86_64-linux-gnu/lib/libzlib.a failed
attempt to open /usr/local/lib/libzlib.so failed
attempt to open /usr/local/lib/libzlib.a failed
attempt to open /lib/libzlib.so failed
attempt to open /lib/libzlib.a failed
attempt to open /usr/lib/libzlib.so failed
attempt to open /usr/lib/libzlib.a failed
/usr/bin/ld.bfd.real: cannot find -lzlib
Ding Ding Ding…
Um es endlich zu beheben, damit ich MySQL mit meiner eigenen Version von ZLIB (anstelle der gebündelten Version) kompilieren konnte:
sudo ln -s /usr/lib/libz.so.1.2.8 /usr/lib/libzlib.so
Voila!
Danke, das war hilfreich. Für andere, die gcc zum Kompilieren und Linken ihres Programms verwenden (anstatt ld direkt zu verwenden), können Sie hinzufügen -Xlinker --verbose zu den Befehlszeilenargumenten von gcc hinzufügen, damit diese Option an ld übergeben wird.
– Benutzer473305
12. Februar 2014 um 11:04 Uhr
Das hat mir auch geholfen. Das Makefile, das ich hatte, erwartete nur statische Bibliotheken, also wurde es verwendet -Wl,-Bstatic. Dadurch wird die Suche nur auf .a-Dateien beschränkt. Die ausführliche Option zeigte dies deutlich. Einmal habe ich entfernt -Wl,-Bstatic gemeinsam genutzte Bibliotheken wurden ebenfalls durchsucht.
– micah94
23. Februar 2014 um 1:21 Uhr
Ich verwende FreeBSD 10. Der neue LLVM Clang cc nimmt ein Argument der Form an -Wl,--verbose und geht --verbose zum Linker.
– Christian – Wiedereinsetzung von Monica C
12. Mai 2014 um 2:32 Uhr
Das nenne ich mal eine perfekte Antwort! Vielen Dank. Es hat viel Zeit gespart. Nur um jemandem wie mir zu helfen. Es kann auch verwendet werden, um pfadbezogene Probleme zu debuggen. Stellen Sie sicher, dass Sie den Pfad mit -L
– sbhatt
9. März 2015 um 20:09 Uhr
@EdwardBlack Siehe diese Antwort. Fügen Sie für gcc einfach hinzu -Wl,--verbose um ausführlich an den Linker zu übergeben.
– Chembrad
9. September 2015 um 19:50 Uhr
Saurabh Bhola
Wenn der Name Ihrer Bibliothek lautet, sagen Sie libxyz.so und es befindet sich auf dem Pfad sagen:
/home/user/myDir
dann, um es mit Ihrem Programm zu verknüpfen:
g++ -L/home/user/myDir -lxyz myprog.cpp -o myprog
Meine Bibliothek ist keine dynamische (.so), sondern eine statische (.a). Kommt das Problem daher?
– ZoOo
23. Mai 2013 um 9:41 Uhr
@ZoOo das sollte normalerweise keine Rolle spielen, der Linker kann mit beiden arbeiten
– djf
23. Mai 2013 um 9:48 Uhr
Eine andere Möglichkeit, Ihre Bibliothek zu verknüpfen, besteht darin, den Namen der Bibliothek mit vollständigem Pfad direkt anzugeben, z. B. g++ .. /path/mylib.a
– Saurabh Bhola
23. Mai 2013 um 9:52 Uhr
Ja aber es geht immer noch nicht. Meine Bibliothek ist ein symbolischer Link, ich denke, das Problem kommt daher, denn wenn ich die Bibliothek im anderen Verzeichnis verwende, funktioniert es!
– ZoOo
23. Mai 2013 um 10:02 Uhr
Zeigt Ihr symbolischer Link korrekt auf die Bibliothek am tatsächlichen Standort??. kannst du die Ausgabe von “ll” auf den symbolischen Link posten.
– Saurabh Bhola
23. Mai 2013 um 10:21 Uhr
Es scheint keine Antwort zu geben, die das sehr häufige Anfängerproblem anspricht, die erforderliche Bibliothek überhaupt nicht zu installieren.
Auf Debianish-Plattformen, wenn libfoo fehlt, können Sie es häufig mit so etwas installieren
apt-get install libfoo-dev
Die -dev Version des Pakets ist für Entwicklungsarbeiten erforderlich, sogar für triviale Entwicklungsarbeiten wie das Kompilieren von Quellcode zum Verknüpfen mit der Bibliothek.
Der Paketname erfordert manchmal einige Dekorationen (libfoo0-dev? foo-dev ohne das lib Präfix? usw.), oder Sie können einfach die Ihrer Distribution verwenden Paketsuche um genau herauszufinden, welche Pakete eine bestimmte Datei enthalten.
(Wenn es mehr als einen gibt, müssen Sie herausfinden, was ihre Unterschiede sind. Die Auswahl des coolsten oder beliebtesten ist eine gängige Abkürzung, aber kein akzeptables Verfahren für ernsthafte Entwicklungsarbeit.)
Für andere Architekturen (insbesondere RPM) gelten ähnliche Verfahren, obwohl die Details anders sein werden.
Das hat mir gerade bei einem Problem geholfen, das ich mit einem neuen Server und Perl hatte. apt-get install libperl-dev hat es für mich sortiert. Danke 🙂
– Andreas Newby
27. März 2017 um 16:58 Uhr
Dies! Sie müssen sich nicht mit dem Makefile herumschlagen
– Byron Whitlock
15. Mai 2017 um 17:36 Uhr
Dies ist wahrscheinlich die häufigste Lösung und hat mir geholfen, Cacti-Spine unter CentOS 7 zu kompilieren. Eine einfache yum install openssl-devel Ich habe es gelöst.
– djluko
30. Mai 2017 um 6:21 Uhr
Dies ist die beste Lösung, wenn Sie feststellen, dass der Symlink mit der Endung .so fehlt, Sie aber einen Symlink wie libfoo.so.6 –> libfoo.so.6.0.2 (zum Beispiel) haben, anstatt den Symlink per zu erstellen Hand. (was bedeutet, dass Sie das Paket libfoo installiert haben, aber nicht libfoo-dev)
– dmaestro12
23. Juni 2018 um 17:29 Uhr
Frosch
Wenn g++ sagt cannot find -l<nameOfTheLibrary>bedeutet dies, dass g++ nach der Datei gesucht hat lib{nameOfTheLibrary}.soaber es konnte es nicht im Suchpfad der gemeinsam genutzten Bibliothek finden, der standardmäßig auf verweist /usr/lib und /usr/local/lib und woanders evtl.
Um dieses Problem zu lösen, sollten Sie entweder die Bibliotheksdatei (lib{nameOfTheLibrary}.so) in diesen Suchpfaden oder verwenden -L Befehlsoption. -L{path} sagt das g++ (eigentlich ld), um Bibliotheksdateien im Pfad zu finden {path} zusätzlich zu den Standardpfaden.
Beispiel: Angenommen, Sie haben eine Bibliothek an /home/taylor/libswift.so, und Sie möchten Ihre App mit dieser Bibliothek verknüpfen. In diesem Fall sollten Sie g++ mit den folgenden Optionen versorgen:
g++ main.cpp -o main -L/home/taylor -lswift
Anmerkung 1: -l Option erhält den Bibliotheksnamen ohne lib und .so an seinem Anfang und Ende.
Anmerkung 2: In manchen Fällen folgt auf den Namen der Bibliotheksdatei beispielsweise die Version libswift.so.1.2. In diesen Fällen kann g++ die Bibliotheksdatei auch nicht finden. Eine einfache Problemumgehung, um dies zu beheben, besteht darin, einen symbolischen Link zu erstellen libswift.so.1.2 namens libswift.so.
Wenn Sie Ihre App mit einer gemeinsam genutzten Bibliothek verknüpfen, ist es erforderlich, dass die Bibliothek verfügbar bleibt, wenn Sie die App ausführen. Zur Laufzeit sucht Ihre App (eigentlich dynamischer Linker) nach ihren Bibliotheken in LD_LIBRARY_PATH. Es ist eine Umgebungsvariable, die eine Liste von Pfaden speichert.
Beispiel: Im Falle unserer libswift.so Beispielsweise kann der dynamische Linker nicht finden libswift.so in LD_LIBRARY_PATH (was auf Standardsuchpfade verweist). Um das Problem zu beheben, sollten Sie diese Variable mit dem Pfad anhängen libswift.so ist in.
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/taylor
Beim Kompilieren mit g++ über make definieren LIBRARY_PATH wenn es nicht angebracht ist, das Makefile mit zu ändern -LMöglichkeit. Ich hatte meine zusätzliche Bibliothek hineingelegt /opt/lib so tat ich:
$ export LIBRARY_PATH=/opt/lib/
und dann rannte make zum erfolgreichen Kompilieren und Verlinken.
Um das Programm mit einer gemeinsam genutzten Bibliothek auszuführen, definieren Sie:
$ export LD_LIBRARY_PATH=/opt/lib/
bevor das Programm ausgeführt wird.
Belter
Zuerst müssen Sie die Namensregel von kennen lxxx:
/usr/bin/ld: cannot find -lc
/usr/bin/ld: cannot find -lltdl
/usr/bin/ld: cannot find -lXtst
lc bedeutet libc.so, lltdl bedeutet libltdl.so, lXtst bedeutet libXts.so.
So ist es lib + lib-name + .so
Sobald wir den Namen kennen, können wir verwenden locate um den Weg dazu zu finden lxxx.so Datei.
$ locate libiconv.so
/home/user/anaconda3/lib/libiconv.so # <-- right here
/home/user/anaconda3/lib/libiconv.so.2
/home/user/anaconda3/lib/libiconv.so.2.5.1
/home/user/anaconda3/lib/preloadable_libiconv.so
/home/user/anaconda3/pkgs/libiconv-1.14-0/lib/libiconv.so
/home/user/anaconda3/pkgs/libiconv-1.14-0/lib/libiconv.so.2
/home/user/anaconda3/pkgs/libiconv-1.14-0/lib/libiconv.so.2.5.1
/home/user/anaconda3/pkgs/libiconv-1.14-0/lib/preloadable_libiconv.so
Wenn Sie es nicht finden können, müssen Sie es installieren yum (Ich benutze CentOS). Normalerweise haben Sie diese Datei, aber sie verknüpft nicht mit der richtigen Stelle.
Verknüpfen Sie es mit der richtigen Stelle, normalerweise ist es das /lib64 oder /usr/lib64
$ sudo ln -s /home/user/anaconda3/lib/libiconv.so /usr/lib64/
Getan!
Referenz: https://i-pogo.blogspot.jp/2010/01/usrbinld-cannot-find-lxxx.html
Koan
Wenn Sie Ihr Programm kompilieren, müssen Sie den Pfad zur Bibliothek angeben; Verwenden Sie in g ++ die Option -L:
g++ myprogram.cc -o myprogram -lmylib -L/path/foo/bar
In welche Wohnung müssen wir umziehen ccmake so, dass die Makefile wird mit der verknüpften Flagge erstellt? Ich möchte meine verlinken -lARToolkitPlus Flagge zu einem Pfad.
– Schaschwat
18. September 2014 um 11:40 Uhr
Benötigen Sie weitere Informationen. Welchen Befehl haben Sie ausgegeben, um Ihr Programm zu kompilieren? Sie können verwenden mach -n zu deinem Ziel um make nur die Befehle ausgeben zu lassen, die es normalerweise aufrufen würde
– djf
23. Mai 2013 um 9:26 Uhr
Poste das Makefile oder den Befehl, den du ausführst.
– Ortwin Angermeier
23. Mai 2013 um 9:38 Uhr
Mein Befehl ist dieser: g++ – objetc1.o objetc2.o objetc3.o objetc4.o -L -l -lpthread -o myexe
– ZoOo
23. Mai 2013 um 9:38 Uhr
Ist die Bibliothek, mit der Sie verknüpfen möchten, mit derselben Architektur (z. B. 32/64 Bit) erstellt? Ist die Bibliothek, die Sie mit einer benutzerdefinierten Bibliothek verknüpfen möchten? Der Bibliotheksname ist wichtig, da er bei Verwendung von mit lib beginnen muss
-lwechseln (z. B. libpthread.so, mit dem Sie bereits verlinken).– Ortwin Angermeier
23. Mai 2013 um 10:10 Uhr
Das Problem lag an meinem symbolischen Link in der Bibliothek, der nicht gut war! Danke für Ihre Hilfe !
– ZoOo
23. Mai 2013 um 11:16 Uhr