usr / bin / ld：-l <nameOfTheLibrary>が見つかりません

プログラムをコンパイルしようとすると、次のエラーが返されます。

usr/bin/ld: cannot find -l<nameOfTheLibrary>

私のメイクファイルでは、コマンドを使用g++して、他のディレクトリにあるライブラリへのシンボリックリンクであるライブラリにリンクしています。

機能させるために追加するオプションはありますか？

ライブラリ名がsayでlibxyz.so、パスにある場合は、次のように言います。

/home/user/myDir

次に、それをプログラムにリンクします。

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

リンカが探しているものを理解するには、冗長モードで実行します。

たとえば、ZLIBサポートを使用してMySQLをコンパイルしようとしたときにこの問題が発生しました。コンパイル中に次のようなエラーを受け取りました：

/usr/bin/ld: cannot find -lzlib

私はいくつかのグーグルを実行し、人々が.soファイルが実際に存在することを確認し、存在しない場合は、zlibなどのバージョン化されたファイルへのシンボリックリンクを作成すると言う、同じ種類の異なる問題に遭遇し続けました。 so.1.2.8。しかし、チェックしたところ、zlib.so DIDが存在しています。だから、きっとそれは問題にならないと思いました。

LD_DEBUG = allでmakeを実行することを提案するインターネット上の別の投稿を見つけました：

LD_DEBUG=all make

TONのデバッグ出力を取得しましたが、実際には役に立ちませんでした。それは何よりも混乱を追加しました。だから、あきらめようとしていました。

その後、私はひらめきを持っていました。実際にldコマンドのヘルプテキストを確認することを考えました。

ld --help

そのことから、冗長モードでldを実行する方法を理解しました（想像してみてください）。

ld -lzlib --verbose

これは私が得た出力です：

==================================================
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

丁、丁、丁...

したがって、最終的にそれを修正して、MySQLを（バンドルされたバージョンではなく）自分のバージョンのZLIBでコンパイルできるようにします。

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

出来上がり！

必要なライブラリを最初にインストールできないという非常に一般的な初心者の問題に対処する答えはないようです。

Debianのプラットフォームでlibfooは、見つからない場合、次のような方法で頻繁にインストールできます。

apt-get install libfoo-dev

-devパッケージのバージョンは、ソースコードをコンパイルしてライブラリにリンクするなどの簡単な開発作業でさえ、開発作業に必要です。

パッケージ名には装飾が必要な場合があります（libfoo0-dev？ プレフィックスfoo-devなしlib？など）。または、ディストリビューションのパッケージ検索を使用して、特定のファイルを提供するパッケージを正確に見つけることができます。

（複数ある場合は、それらの違いを見つける必要があります。最もクールなものまたは最も人気のあるものを選択することが一般的なショートカットですが、深刻な開発作業には受け入れられない手順です。）

他のアーキテクチャー（特にRPM）では、同様の手順が適用されますが、詳細は異なります。

コンパイル時間

G ++は言うときcannot find -l<nameOfTheLibrary>、それはファイルを探し++そのグラムを意味しlib{nameOfTheLibrary}.so、それはデフォルトのポイントによると、共有ライブラリの検索パスでそれを見つけることができなかった/usr/libし、/usr/local/lib多分とどこか。

この問題を解決するにはlib{nameOfTheLibrary}.so、これらの検索パスにライブラリファイル（）を提供するか、-Lコマンドオプションを使用する必要があります。デフォルトのパスに加えて、パス内のライブラリファイルを検索するよう-L{path}にg ++（実際にはld）に指示し{path}ます。

例：にライブラリがあり/home/taylor/libswift.so、アプリをこのライブラリにリンクするとします。この場合、g ++に次のオプションを指定する必要があります。

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

• 注1：-lオプションは、ライブラリ名を取得することなく、 libかつ.soその最初と最後に。

• 注2：たとえば、ライブラリファイル名の後にバージョンが続く場合がありますlibswift.so.1.2。これらの場合、g ++もライブラリファイルを見つけることができません。この問題を解決するための簡単な回避策は、シンボリックリンクを作成しているlibswift.so.1.2と呼ばれますlibswift.so。

ランタイム

アプリを共有ライブラリにリンクする場合、アプリを実行するときはいつでもライブラリを利用できるようにする必要があります。ランタイムでは、アプリ（実際には動的リンカー）がでライブラリを探しますLD_LIBRARY_PATH。パスのリストを格納する環境変数です。

例：私たちの場合にはlibswift.so、例えば、動的リンカーは見つけることができないlibswift.soでLD_LIBRARY_PATH（デフォルトの検索パスにどの点）。問題を修正するには、パスlibswift.soが入っている変数を追加する必要があります。

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/taylor

オプションを指定してMakefileを変更することが適切でない可能性がある場合、g++via makedefine を使用したコンパイル中に。追加のライブラリを入れていたので、次のようにしました。LIBRARY_PATH-L/opt/lib

$ export LIBRARY_PATH=/opt/lib/

そして、makeコンパイルとリンクを成功させるために走りました。

共有ライブラリを定義してプログラムを実行するには：

$ export LD_LIBRARY_PATH=/opt/lib/

プログラムを実行する前。

まず、次の命名規則を知っておく必要がありますlxxx。

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

lc手段libc.so、lltdl手段libltdl.so、lXtst手段libXts.so。

だから、それはlib+ lib-name+.so

名前がわかったら、を使用locateしてこのlxxx.soファイルのパスを見つけることができます。

$ 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

見つからない場合は、yum（CentOSを使用して）インストールする必要があります。通常、このファイルがありますが、正しい場所にリンクされていません。

通常、それは、適切な場所にそれをリンクし/lib64たり/usr/lib64

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

できた！

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

プログラムをコンパイルするときは、ライブラリへのパスを指定する必要があります。g ++では-Lオプションを使用します。

g++ myprogram.cc -o myprogram -lmylib -L/path/foo/bar

このエラーは、シンボリックリンクがダイナミックライブラリ.soへのリンクである場合にも発生する可能性がありますが、従来の理由により-staticリンクフラグに表示されます。その場合は、削除してみてください。

ライブラリの場所（lxxx.soなど）を確認します。

locate lxxx.so

/usr/libフォルダーにない場合は、次のように入力します。

sudo cp yourpath/lxxx.so /usr/lib

できました。

すでに与えられた回答とは別に、*。soファイルが存在するが適切に名前が付けられていない場合もあります。または、*。soファイルは存在するが、別のユーザー/ルートが所有している場合もあります。

問題1：不適切な名前

ファイルをリンクする場合-l<nameOfLibrary> 、ライブラリファイル名は次の形式でなければなりません。ファイルlib<nameOfLibrary> しかない場合は、ファイル名を<nameOfLibrary>.so変更してください。

問題2：間違った所有者

これが問題ではないことを確認するには-行います

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

ファイルがrootまたは別のユーザーによって所有されている場合は、

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

私がリンクしようとしていたライブラリは、非標準の名前（つまり、「lib」のプレフィックスが付いていない）であることが判明したため、このようなコマンドを使用してコンパイルすることを推奨しました-

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

これが私のラップトップのUbuntu情報です。

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

Locateを使用して、boost_filesystemおよびboost_systemの.soファイルを検索します

locate libboost_filesystem
locate libboost_system

次に、.soファイルを/ usr / libにリンクし、名前を.soに変更します。

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

できた！Rパッケージvelocyto.Rが正常にインストールされました！

同じエラーメッセージが表示されました。

をcmockaとして構築soし、実行可能ファイルにリンクしようとしました。しかし、ld常に以下の不満があります：

/ usr / bin / ld：-lcmockaが見つかりません

cmockaビルド後に3つのファイルが生成されることがわかります。

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

1と2はシンボルリンクであり、3のみが実際のファイルです。

1を自分のライブラリフォルダーにコピーしただけで、 ld、3が見つかりませんでした。

3本全部コピーした後ld。