usr / bin / ld: -l <nameOfTheLibrary> kann nicht gefunden werden

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 den Link zu meiner Bibliothek. Dies ist ein symbolischer Link zu meiner Bibliothek in einem anderen Verzeichnis.

Gibt es eine Option zum Hinzufügen, damit es funktioniert?

Wenn Ihr Bibliotheksname say lautet libxyz.sound er sich auf dem Pfad befindet, sagen Sie:

/home/user/myDir

dann, um es mit Ihrem Programm zu verknüpfen:

g++ -L/home/user/myDir -lxyz myprog.cpp -o myprog

Um herauszufinden, wonach der Linker sucht, führen Sie ihn im ausführlichen Modus aus.

Dieses Problem ist beispielsweise beim Kompilieren von MySQL mit ZLIB-Unterstützung aufgetreten. Beim Kompilieren wurde folgende Fehlermeldung angezeigt:

/usr/bin/ld: cannot find -lzlib

Ich habe ein bisschen Googl'ing gemacht und bin immer wieder auf verschiedene Probleme der gleichen Art gestoßen, bei denen die Leute sagten, sie würden sicherstellen, dass die .so-Datei tatsächlich existiert. Wenn dies nicht der Fall ist, erstellen Sie einen Symlink zu der versionierten Datei, z. B. zlib. so.1.2.8. Aber als ich nachgesehen habe, war zlib.so DID vorhanden. Also, dachte ich, das könnte doch nicht das Problem sein.

Ich bin auf einen anderen Beitrag im Internet gestoßen, der vorschlug, make mit LD_DEBUG = all auszuführen:

LD_DEBUG=all make

Obwohl ich eine TONNE Debugging-Ausgabe habe, war es nicht wirklich hilfreich. Es fügte mehr Verwirrung als alles andere hinzu. Also wollte ich aufgeben.

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 erhalten 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 kompilieren kann (anstatt mit der mitgelieferten Version):

sudo ln -s /usr/lib/libz.so.1.2.8 /usr/lib/libzlib.so

Voila!

Es scheint keine Antwort zu geben, die das sehr häufige Anfängerproblem behebt, die erforderliche Bibliothek überhaupt nicht zu installieren.

Wenn auf Debianish-Plattformen libfooetwas fehlt, können Sie es häufig mit etwas wie installieren

apt-get install libfoo-dev

Die -devVersion des Pakets wird für Entwicklungsarbeiten benötigt, auch für triviale Entwicklungsarbeiten wie das Kompilieren von Quellcode zur Verknüpfung mit der Bibliothek.

Der Paketname erfordert manchmal einige Dekorationen ( libfoo0-dev? foo-devOhne das libPräfix? Usw.), oder Sie können einfach Ihre Distributionen verwenden Paket suchen genau , um herauszufinden , welche Pakete eine bestimmte Datei zur Verfügung stellen.

(Wenn es mehr als eine gibt, müssen Sie herausfinden, wo ihre Unterschiede liegen. Die Auswahl der coolsten oder beliebtesten ist eine häufige Abkürzung, aber kein akzeptables Verfahren für ernsthafte Entwicklungsarbeiten.)

Für andere Architekturen (insbesondere RPM) gelten ähnliche Verfahren, obwohl die Details unterschiedlich sind.

Kompilierungszeit

Wenn g ++ sagt cannot find -l<nameOfTheLibrary>, bedeutet dies, dass g ++ nach der Datei gesucht lib{nameOfTheLibrary}.sohat, sie jedoch nicht im Suchpfad der gemeinsam genutzten Bibliothek gefunden hat, der standardmäßig auf /usr/libund /usr/local/libund woanders verweist .

Um dieses Problem zu beheben, sollten Sie entweder die Bibliotheksdatei ( lib{nameOfTheLibrary}.so) in diesen Suchpfaden angeben oder die -LBefehlsoption verwenden. -L{path}Weist das g ++ (tatsächlich ld) an, {path}zusätzlich zu den Standardpfaden Bibliotheksdateien im Pfad zu finden .

Beispiel: Angenommen, Sie haben eine Bibliothek unter /home/taylor/libswift.sound möchten Ihre App mit dieser Bibliothek verknüpfen. In diesem Fall sollten Sie g ++ mit folgenden Optionen versorgen:

g++ main.cpp -o main -L/home/taylor -lswift

• Hinweis 1 : Mit der -lOption wird der Bibliotheksname ohne lib und .soam Anfang und Ende abgerufen.

• Hinweis 2 : In einigen Fällen folgt auf den Namen der Bibliotheksdatei beispielsweise die Version libswift.so.1.2. In diesen Fällen kann g ++ auch die Bibliotheksdatei nicht finden. Eine einfache Problemumgehung, um dies zu beheben, besteht darin, eine symbolische Verknüpfung zu libswift.so.1.2aufgerufen zu erstellen libswift.so.

Laufzeit

Wenn Sie Ihre App mit einer gemeinsam genutzten Bibliothek verknüpfen, muss die Bibliothek immer verfügbar sein, 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: Bei unserem libswift.soBeispiel kann dynamische Linker nicht finden libswift.soinLD_LIBRARY_PATH (der auf Standard - Suchpfade). Um das Problem zu beheben, sollten Sie diese Variable an den Pfad anhängen, in dem sie sich libswift.sobefindet.

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/taylor

Während der Kompilierung mit g++via makedefinieren, LIBRARY_PATHob es möglicherweise nicht angebracht ist, das Makefile mit der -LOption zu ändern . Ich hatte meine zusätzliche Bibliothek eingerichtet, /opt/libalso tat ich:

$ export LIBRARY_PATH=/opt/lib/

und lief dann makefür eine erfolgreiche Kompilierung und Verknüpfung.

Um das Programm mit einer gemeinsam genutzten Bibliothek auszuführen, definieren Sie:

$ export LD_LIBRARY_PATH=/opt/lib/

vor dem Ausführen des Programms.

Zunächst müssen Sie die Namensregel kennen von lxxx:

/usr/bin/ld: cannot find -lc
/usr/bin/ld: cannot find -lltdl
/usr/bin/ld: cannot find -lXtst

lcbedeutet libc.so, lltdlbedeutet libltdl.so, lXtstbedeutet libXts.so.

Es ist also lib+ lib-name+.so

Sobald wir den Namen kennen, können wir locateden Pfad dieser lxxx.soDatei finden.

$ 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 mit installieren yum(ich verwende CentOS). Normalerweise haben Sie diese Datei, aber sie ist nicht mit der richtigen Stelle verknüpft.

Verknüpfe es mit dem richtigen Ort, normalerweise ist es /lib64oder/usr/lib64

$ sudo ln -s /home/user/anaconda3/lib/libiconv.so /usr/lib64/

Erledigt!

ref: https://i-pogo.blogspot.jp/2010/01/usrbinld-cannot-find-lxxx.html

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

Dieser Fehler kann auch auftreten, wenn sich die symbolische Verknüpfung zu einer dynamischen Bibliothek befindet, aber aus älteren Gründen -staticunter den Verknüpfungsflags angezeigt wird . Wenn ja, entfernen Sie es.

Überprüfen Sie den Speicherort Ihrer Bibliothek, z. B. lxxx.so:

locate lxxx.so

Wenn es sich nicht im /usr/libOrdner befindet, geben Sie Folgendes ein:

sudo cp yourpath/lxxx.so /usr/lib

Erledigt.

Abgesehen von den bereits gegebenen Antworten kann es auch vorkommen, dass die Datei * .so vorhanden ist, aber nicht richtig benannt ist. Oder es kann vorkommen, dass die Datei * .so vorhanden ist, aber einem anderen Benutzer / Root gehört.

Problem 1: Falscher Name

Wenn Sie die Datei wie -l<nameOfLibrary> folgt verknüpfen, MUSS der Name der Bibliotheksdatei die Form haben. lib<nameOfLibrary> Wenn Sie nur eine <nameOfLibrary>.soDatei haben, benennen Sie diese um!

Ausgabe 2: Falscher Besitzer

Um zu überprüfen, ob dies nicht das Problem ist, gehen Sie wie folgt vor

ls -l /path/to/.so/file

Wenn die Datei Root oder einem anderen Benutzer gehört, müssen Sie dies tun

sudo chown yourUserName:yourUserName /path/to/.so/file

Die Bibliothek, mit der ich eine Verknüpfung herstellen wollte, hatte einen nicht standardmäßigen Namen (dh es wurde kein 'lib' vorangestellt). Daher wurde empfohlen, einen solchen Befehl zum Kompilieren zu verwenden.

gcc test.c -Iinclude lib/cspice.a -lm

Hier sind Ubuntu-Informationen zu meinem Laptop.

lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.2 LTS
Release:    18.04
Codename:   bionic

Ich benutze find, um die .so-Dateien für boost_filesystem und boost_system zu finden

locate libboost_filesystem
locate libboost_system

Verknüpfen Sie dann .so-Dateien mit / usr / lib und benennen Sie sie in .so um

sudo ln -s /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.65.1 /usr/lib/libboost_filesystem.so
sudo ln -s /usr/lib/x86_64-linux-gnu/libboost_system.so.1.65.1 /usr/lib/libboost_system.so

Erledigt! R-Paket velocyto.R wurde erfolgreich installiert!

Ich habe die gleiche Fehlermeldung festgestellt.

Ich habe das cmockaals erstellt sound versucht, es mit meiner ausführbaren Datei zu verknüpfen. Aber ldbeschwert sich immer unten:

/ usr / bin / ld: -lcmocka kann nicht gefunden werden

Es stellt sich heraus, dass nach dem Erstellen 3 Dateien generiert cmockawurden:

1. libcmocka.so
2. libcmocka.so.0
3. libcmocka.so.0.7.0

1 und 2 sind Symbolverknüpfungen und nur 3 ist die echte Datei.

Ich habe nur die 1 in meinen Bibliotheksordner kopiert, wo ich lddie 3 nicht finden konnte.

Nachdem ich alle 3 kopiert habe, ldfunktioniert.