Linux usr/bin/ld: 找不到 -l<nameOfTheLibrary>

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

提问by ZoOo

I'm trying to compile my program and it returns this error :

我正在尝试编译我的程序并返回此错误：

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

in my makefile I use the command g++and link to my library which is a symbolic link to my library located on an other directory.

在我的 makefile 中，我使用命令g++并链接到我的库，这是指向位于其他目录中的库的符号链接。

Is there an option to add to make it work please?

是否有添加选项以使其工作？

采纳答案by Saurabh Bhola

If your library name is say libxyz.soand it is located on path say:

如果您的库名称是 saylibxyz.so并且它位于路径上，请说：

/home/user/myDir

then to link it to your program:

然后将其链接到您的程序：

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

回答by koan

When you compile your program you must supply the path to the library; in g++ use the -L option:

当你编译你的程序时，你必须提供库的路径；在 g++ 中使用 -L 选项：

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

回答by dcarrith

To figure out what the linker is looking for, run it in verbose mode.

要弄清楚链接器正在寻找什么，请以详细模式运行它。

For example, I encountered this issue while trying to compile MySQL with ZLIB support. I was receiving an error like this during compilation:

例如，我在尝试编译支持 ZLIB 的 MySQL 时遇到了这个问题。我在编译过程中收到这样的错误：

/usr/bin/ld: cannot find -lzlib

I did some Googl'ing and kept coming across different issues of the same kind where people would say to make sure the .so file actually exists and if it doesn't, then create a symlink to the versioned file, for example, zlib.so.1.2.8. But, when I checked, zlib.so DID exist. So, I thought, surely that couldn't be the problem.

我做了一些谷歌搜索，并不断遇到相同类型的不同问题，人们会说要确保 .so 文件确实存在，如果不存在，则创建一个指向版本文件的符号链接，例如 zlib。所以.1.2​​.8。但是，当我检查时，zlib.so 确实存在。所以，我想，这肯定不是问题。

I came across another post on the Internets that suggested to run make with LD_DEBUG=all:

我在互联网上看到另一篇文章，建议使用 LD_DEBUG=all 运行 make：

LD_DEBUG=all make

Although I got a TON of debugging output, it wasn't actually helpful. It added more confusion than anything else. So, I was about to give up.

虽然我得到了大量的调试输出，但实际上并没有帮助。它比其他任何事情都增加了更多的混乱。所以，我都快要放弃了。

Then, I had an epiphany. I thought to actually check the help text for the ld command:

然后，我顿悟了。我想实际检查 ld 命令的帮助文本：

ld --help

From that, I figured out how to run ld in verbose mode (imagine that):

从那以后，我想出了如何在详细模式下运行 ld （想象一下）：

ld -lzlib --verbose

This is the output I got:

这是我得到的输出：

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

叮、叮、叮……

So, to finally fix it so I could compile MySQL with my own version of ZLIB (rather than the bundled version):

所以，为了最终修复它，我可以用我自己的 ZLIB 版本（而不是捆绑版本）编译 MySQL：

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

Voila!

瞧！

回答by Finn ?rup Nielsen

During compilation with g++via makedefine LIBRARY_PATHif it may not be appropriate to change the Makefile with the -Loption. I had put my extra library in /opt/libso I did:

在使用g++via 进行编译期间，make定义LIBRARY_PATH是否不适合使用该-L选项更改 Makefile 。我已经把我额外的图书馆放进去了，/opt/lib所以我做了：

$ export LIBRARY_PATH=/opt/lib/

and then ran makefor successful compilation and linking.

然后运行make成功编译和链接。

To run the program with a shared library define:

要使用共享库运行程序，请定义：

$ export LD_LIBRARY_PATH=/opt/lib/

before executing the program.

在执行程序之前。

回答by frogatto

Compile Time

编译时间

When g++ says cannot find -l<nameOfTheLibrary>, it means that g++ looked for the file lib{nameOfTheLibrary}.so, but it couldn't find it in the shared library search path, which by default points to /usr/liband /usr/local/liband somewhere else maybe.

当 g++ 说 时cannot find -l<nameOfTheLibrary>，这意味着 g++ 查找了该文件lib{nameOfTheLibrary}.so，但它在共享库搜索路径中找不到它，默认情况下，该路径指向/usr/liband/usr/local/lib和其他地方。

To resolve this problem, you should either provide the library file (lib{nameOfTheLibrary}.so) in those search paths or use -Lcommand option. -L{path}tells the g++ (actually ld) to find library files in path {path}in addition to default paths.

要解决此问题，您应该lib{nameOfTheLibrary}.so在这些搜索路径中提供库文件 ( ) 或使用-L命令选项。除了默认路径之外，还-L{path}告诉 g++（实际上ld）在路径{path}中查找库文件。

Example:Assuming you have a library at /home/taylor/libswift.so, and you want to link your app to this library. In this case you should supply the g++ with the following options:

示例：假设您在 有一个库/home/taylor/libswift.so，并且您想将您的应用程序链接到该库。在这种情况下，您应该为 g++ 提供以下选项：

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

• Note 1: -loption gets the library name withoutliband .soat its beginning and end.

• Note 2: In some cases, the library file name is followed by its version, for instance libswift.so.1.2. In these cases, g++ also cannot find the library file. A simple workaround to fix this is creating a symbolic link to libswift.so.1.2called libswift.so.

• 注1：-l选项得到库名没有lib和.so在它的开始和结束。

• 注 2：在某些情况下，库文件名后跟其版本，例如libswift.so.1.2. 在这些情况下，g++ 也找不到库文件。解决此问题的一个简单解决方法是创建一个指向libswift.so.1.2被调用的符号链接libswift.so。

---

---

Runtime

运行

When you link your app to a shared library, it's required that library stays available whenever you run the app. In runtime your app (actually dynamic linker) looks for its libraries in LD_LIBRARY_PATH. It's an environment variable which stores a list of paths.

当您将应用程序链接到共享库时，要求该库在您运行该应用程序时始终可用。在运行时，您的应用程序（实际上是动态链接器）在LD_LIBRARY_PATH. 它是一个存储路径列表的环境变量。

Example:In case of our libswift.soexample, dynamic linker cannot find libswift.soin LD_LIBRARY_PATH(which points to default search paths). To fix the problem you should append that variable with the path libswift.sois in.

示例：在我们的libswift.so示例中，动态链接器找不到libswift.soin LD_LIBRARY_PATH（指向默认搜索路径）。要解决此问题，您应该将路径附加到该变量libswift.so中。

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/taylor

回答by Vzbux

This error may also be brought about if the symbolic link is to a dynamic library, .so, but for legacy reasons -staticappears among the link flags. If so, try removing it.

如果符号链接指向动态库 .so，也可能导致此错误，但由于遗留原因-static，链接标志中会出现此错误。如果是这样，请尝试将其删除。

回答by Brian Burns

The library I was trying to link to turned out to have a non-standard name (i.e. wasn't prefixed with 'lib'), so they recommended using a command like this to compile it -

我试图链接的库结果证明具有非标准名称（即没有以“lib”为前缀），因此他们建议使用这样的命令来编译它-

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

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

回答by tripleee

There does not seem to be any answer which addresses the very common beginner problem of failing to install the required library in the first place.

似乎没有任何答案可以解决非常常见的初学者无法首先安装所需库的问题。

On Debianish platforms, if libfoois missing, you can frequently install it with something like

在 Debianish 平台上，如果libfoo缺少，您可以经常使用类似的东西安装它

apt-get install libfoo-dev

The -devversion of the package is required for development work, even trivial development work such as compiling source code to link to the library.

-dev开发工作需要包的版本，即使是编译源代码链接到库等琐碎的开发工作。

The package name will sometimes require some decorations (libfoo0-dev? foo-devwithout the libprefix? etc), or you can simply use your distro's package searchto find out precisely which packages provide a particular file.

包名有时需要一些修饰（libfoo0-dev? foo-dev没有lib前缀？等），或者您可以简单地使用发行版的包搜索来准确找出哪些包提供特定文件。

(If there is more than one, you will need to find out what their differences are. Picking the coolest or the most popular is a common shortcut, but not an acceptable procedure for any serious development work.)

（如果有多个，您将需要找出它们之间的区别。选择最酷或最受欢迎的是一种常见的捷径，但对于任何严肃的开发工作来说，这不是一个可接受的过程。）

For other architectures (most notably RPM) similar procedures apply, though the details will be different.

对于其他体系结构（尤其是 RPM），类似的过程适用，但细节会有所不同。

回答by Belter

First, you need to know the naming rule of lxxx:

首先，您需要了解 的命名规则lxxx：

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

lcmeans libc.so, lltdlmeans libltdl.so, lXtstmeans libXts.so.

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

So, it is lib+ lib-name+ .so

所以，它是lib+ lib-name+.so

---

---

Once we know the name, we can use locateto find the path of this lxxx.sofile.

一旦我们知道名称，我们就可以使用它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

If you cannot find it, you need to install it by yum(I use CentOS). Usually you have this file, but it does not link to right place.

如果找不到，则需要通过yum（我使用CentOS）安装它。通常你有这个文件，但它没有链接到正确的地方。

---

---

Link it to the right place, usually it is /lib64or /usr/lib64

将其链接到正确的位置，通常是/lib64或/usr/lib64

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

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

Done!

完毕！

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

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

回答by hua

Check the location of your library, for example lxxx.so:

检查库的位置，例如 lxxx.so：

locate lxxx.so

If it is not in the /usr/libfolder, type this:

如果它不在/usr/lib文件夹中，请键入：

sudo cp yourpath/lxxx.so /usr/lib

Done.

完毕。