Question

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

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

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

是否可以选择添加以使其正常工作？

Answer 1

要确定链接器要查找的内容，请以详细模式运行它。

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

/usr/bin/ld: cannot find -lzlib

我做了一些Googl'ing并且遇到了同样类型的不同问题，人们会说要确保.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

丁丁丁丁......

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

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

瞧！

Answer 2

如果您的图书馆名称是libxyz.so，并且位于路径上，请说：

/home/user/myDir

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

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

Answer 3

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

在Debianish平台上，如果缺少libfoo，您可以经常使用类似

的方式安装它

apt-get install libfoo-dev

开发工作需要-dev版本的软件包，甚至是简单的开发工作，例如编译链接到库的源代码。

包名有时会需要一些装饰（libfoo0-dev？foo-dev没有lib前缀？等），或者您只需使用发行版的package search来查找确切地说哪些包提供了特定的文件。

（如果不止一个，你需要找出他们之间的差异。选择最酷或最受欢迎的是一个共同的捷径，但不是任何认真开发工作的可接受程序。）

对于其他架构（最值得注意的是RPM），类似的程序适用，但细节会有所不同。

Answer 4

使用g++通过make定义LIBRARY_PATH进行编译时，如果使用-L选项更改Makefile可能不合适。我把我的额外库放在/opt/lib中，所以我做了：

$ export LIBRARY_PATH=/opt/lib/

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

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

$ export LD_LIBRARY_PATH=/opt/lib/

执行程序之前。

Answer 5

编译时间

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

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

示例：假设您在{path}有一个图书馆，并且您想要将您的应用链接到此图书馆。在这种情况下，您应该为g ++提供以下选项：

/home/taylor/libswift.so

注1 ：g++ main.cpp -o main -L/home/taylor -lswift选项在其开头和结尾处获取库名称，但不包含 -l和lib
注意2 ：在某些情况下，库文件名后跟其版本，例如.so。在这些情况下，g ++也找不到库文件。解决此问题的一种简单解决方法是创建一个名为libswift.so.1.2 libswift.so.1.2的符号链接。

运行

当您将应用程序链接到共享库时，只要您运行该应用程序，就要求该库保持可用状态。在运行时，您的应用程序（实际上是动态链接器）在libswift.so中查找其库。它是一个存储路径列表的环境变量。

示例：如果是LD_LIBRARY_PATH示例，则动态链接器无法在libswift.so中找到libswift.so（指向默认搜索路径）。要解决此问题，您应该附加路径为LD_LIBRARY_PATH的变量。

libswift.so

Answer 6

首先，您需要了解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/

完成！

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

Answer 7

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

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

Answer 8

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

Answer 9

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

locate lxxx.so

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

sudo cp yourpath/lxxx.so /usr/lib

完成。

Answer 10

除了已经给出的答案之外，也可能是* .so文件存在但未正确命名的情况。或者可能是* .so文件存在，但它由另一个用户/ root拥有。

问题1：名称不正确

如果您将文件链接为-l<nameOfLibrary> 那么库文件名必须是lib<nameOfLibrary>形式如果您只有<nameOfLibrary>.so个文件，请将其重命名！

问题2：错误的所有者

要验证这不是问题 - 请执行

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

如果文件由root或其他用户拥有，则需要执行

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

Answer 11

我试图链接的库竟然有一个非标准名称（即没有前缀'lib'），所以他们建议使用这样的命令来编译它 -

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

Answer 12

这是我笔记本电脑的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已成功安装！

Answer 13

我遇到了同样的错误消息。

我将cmocka构建为so，并尝试将其链接到我的可执行文件。但是ld总是在下面抱怨：

/ usr / bin / ld：找不到 -lcmocka

事实证明，构建cmocka后生成了3个文件：

libcmocka.so
libcmocka.so.0
libcmocka.so.0.7.0

1和2是符号链接，只有3是真实文件。

我只将1复制到了我的库文件夹中，其中ld找不到3。

我全部复制了3个后，ld起作用了。

Answer 14

我在使用Centos 7.8的新VM上编译LXC时遇到了这个问题。我尝试了以上所有方法，但均失败了。有人建议从编译器配置中删除-static标志，但我不想更改任何内容。

唯一有用的是安装glibc-static并重试。希望能对某人有所帮助。

usr / bin / ld：找不到-l <nameofthelibrary> </nameofthelibrary>

14 个答案:

编译时间

运行