未能链接到适当的库/对象文件或编译实现文件

通常，每个翻译单元都会生成一个包含该翻译单元中定义的符号定义的对象文件。要使用这些符号，必须链接这些对象文件。

在gcc下，您可以指定要在命令行中链接在一起的所有对象文件，或者一起编译实现文件。

g++ -o test objectFile1.o objectFile2.o -lLibraryName

-我。。。必须位于任何.o/.c/.cpp文件的右侧。

这里的libraryName只是库的裸名，没有特定于平台的添加。例如，在Linux上，库文件通常被称为libfoo.So，但您只能编写-lfo。在Windows上，相同的文件可能被称为foo.lib，但您将使用相同的参数。您可能需要添加目录，在该目录中可以使用-Lûdirectory›找到这些文件。确保不要在-l或-l后面写空格。

对于Xcode：添加用户标题搜索路径->添加库搜索路径->将实际的库引用拖放到项目文件夹中。

在MSVS下，添加到项目中的文件会自动将其对象文件链接在一起，并生成一个lib文件（常见用法）。要在单独的项目中使用符号，您需要需要在项目设置中包含lib文件。这是在项目财产的链接器部分的Input->Additional Dependencies中完成的。（指向lib文件的路径应为在Linker->General->Additional Library Directories中添加）当使用随lib文件提供的第三方库时，失败通常会导致错误。

还可能发生忘记将文件添加到编译中的情况，在这种情况下，不会生成对象文件。在gcc中，您可以将文件添加到命令行。在MSVS中，将文件添加到项目将使其自动编译（尽管文件可以手动从构建中单独排除）。

在Windows编程中，未链接必要库的标志是未解析符号的名称以__imp_开头。在文档中查找函数的名称，它应该指出您需要使用哪个库。例如，MSDN将信息放在名为“库”的部分中每个函数底部的框中。

指定相互依赖的链接库的顺序是错误的。

如果库相互依赖，则库的链接顺序也很重要。通常，如果库A依赖于库B，那么在链接器标志中，libA必须出现在libB之前。

例如：

// B.h
#ifndef B_H
#define B_H

struct B {
    B(int);
    int x;
};

#endif

// B.cpp
#include "B.h"
B::B(int xx) : x(xx) {}

// A.h
#include "B.h"

struct A {
    A(int x);
    B b;
};

// A.cpp
#include "A.h"

A::A(int x) : b(x) {}

// main.cpp
#include "A.h"

int main() {
    A a(5);
    return 0;
};

创建库：

$ g++ -c A.cpp
$ g++ -c B.cpp
$ ar rvs libA.a A.o 
ar: creating libA.a
a - A.o
$ ar rvs libB.a B.o 
ar: creating libB.a
a - B.o

编译：

$ g++ main.cpp -L. -lB -lA
./libA.a(A.o): In function `A::A(int)':
A.cpp:(.text+0x1c): undefined reference to `B::B(int)'
collect2: error: ld returned 1 exit status
$ g++ main.cpp -L. -lA -lB
$ ./a.out

再说一遍，顺序很重要！

编译器/IDE中的错误

我最近遇到了这个问题，结果发现这是Visual Studio Express 2013中的一个错误。我不得不从项目中删除一个源文件，然后重新添加它以克服错误。

如果您认为这可能是编译器/IDE中的错误，请尝试以下步骤：

清理项目（一些IDE可以选择这样做，您也可以手动删除对象文件）尝试启动新项目，从原始代码复制所有源代码。

链接在引用库的对象文件之前使用库

您正在尝试编译程序并将其与GCC工具链链接。链接指定了所有必要的库和库搜索路径如果libfoo依赖于libbar，那么链接会正确地将libfoo放在libbar之前。链接失败，对某些错误的引用未定义。但是所有未定义的东西都在你的头文件中声明#并且实际上是在您链接的库中定义的。

示例在C中。它们也可以是C++

一个涉及您自己构建的静态库的最小示例

my_lib.c文件

#include "my_lib.h"
#include <stdio.h>

void hw(void)
{
    puts("Hello World");
}

my_lib.h

#ifndef MY_LIB_H
#define MT_LIB_H

extern void hw(void);

#endif

例如1.c

#include <my_lib.h>

int main()
{
    hw();
    return 0;
}

构建静态库：

$ gcc -c -o my_lib.o my_lib.c
$ ar rcs libmy_lib.a my_lib.o

编译程序：

$ gcc -I. -c -o eg1.o eg1.c

尝试将其与libmy_lib.a链接，但失败：

$ gcc -o eg1 -L. -lmy_lib eg1.o 
eg1.o: In function `main':
eg1.c:(.text+0x5): undefined reference to `hw'
collect2: error: ld returned 1 exit status

如果您在一个步骤中编译和链接，则会得到相同的结果，例如：

$ gcc -o eg1 -I. -L. -lmy_lib eg1.c
/tmp/ccQk1tvs.o: In function `main':
eg1.c:(.text+0x5): undefined reference to `hw'
collect2: error: ld returned 1 exit status

一个涉及共享系统库的最小示例，即压缩库libz

例如2.c

#include <zlib.h>
#include <stdio.h>

int main()
{
    printf("%s\n",zlibVersion());
    return 0;
}

编译程序：

$ gcc -c -o eg2.o eg2.c

尝试将程序与libz链接并失败：

$ gcc -o eg2 -lz eg2.o 
eg2.o: In function `main':
eg2.c:(.text+0x5): undefined reference to `zlibVersion'
collect2: error: ld returned 1 exit status

如果您一次编译并链接：

$ gcc -o eg2 -I. -lz eg2.c
/tmp/ccxCiGn7.o: In function `main':
eg2.c:(.text+0x5): undefined reference to `zlibVersion'
collect2: error: ld returned 1 exit status

示例2的一个变体涉及pkg配置：

$ gcc -o eg2 $(pkg-config --libs zlib) eg2.o 
eg2.o: In function `main':
eg2.c:(.text+0x5): undefined reference to `zlibVersion'

你做错了什么？

在要链接的对象文件和库序列中程序，您将库放在引用的对象文件之前他们您需要将库放在引用对他们来说。

正确链接示例1：

$ gcc -o eg1 eg1.o -L. -lmy_lib

成功：

$ ./eg1 
Hello World

正确链接示例2：

$ gcc -o eg2 eg2.o -lz

成功：

$ ./eg2 
1.2.8

正确链接示例2 pkg配置变体：

$ gcc -o eg2 eg2.o $(pkg-config --libs zlib) 
$ ./eg2
1.2.8

解释

从这里开始，阅读是可选的。

默认情况下，GCC在您的发行版上生成的链接命令，在中从左到右使用链接中的文件命令行序列。当它发现一个文件引用了某个并且不包含其定义，to将搜索定义在更右边的文件中。如果它最终找到了定义解析引用。如果任何引用在结束时仍未解决，链接失败：链接器没有向后搜索。

首先，示例1，使用静态库my_lib.a

静态库是对象文件的索引存档。当链接器在链接序列中找到-lmy-lib，并指出这是指到静态库/libmy_lib.a，它想知道您的程序是否需要libmy_lib.a中的任何对象文件。

libmy_lib.a中只有一个对象文件，即my_lib.o，并且只定义了一个对象在my_lib.o中，即函数hw。

链接器将决定您的程序需要my_lib.o，如果并且仅当它已经知道您的程序在一个或多个对象文件中引用hw添加到程序中，并且没有添加任何对象文件包含hw的定义。

如果这是真的，那么链接器将从库中提取my_lib.o的副本，并将其添加到您的程序中。然后，您的程序包含hw的定义，因此其对hw的引用被解析。

当您尝试链接程序时，如：

$ gcc -o eg1 -L. -lmy_lib eg1.o

链接器在看到时没有将eg1.o添加到程序中-lmy_库。因为在这一点上，它还没有看到eg1.o。您的程序尚未引用hw:it根本没有做任何引用，因为它做的所有引用在eg1.o中。

因此，链接器不会将my_lib.o添加到程序中，并且没有其他内容用于libmy_lib.a。

接下来，它找到eg1.o，并将其添加到程序中。中的对象文件链接序列总是添加到程序中。现在，该程序使对hw的引用，并且不包含hw的定义；但是链接序列中没有任何内容可以提供缺失释义对hw的引用最终无法解析，链接失败。

第二，示例2，使用共享库libz

共享库不是对象文件或类似文件的存档更像是一个没有主功能的程序而是公开它定义的多个其他符号程序可以在运行时使用它们。

今天，许多Linux发行版配置其GCC工具链，以便其语言驱动程序（GCC、g++、gfortran等）指示系统链接器（ld）根据需要链接共享库。你有一个这样的发行版。

这意味着当链接器在链接序列中找到-lz，并发现这是指到共享库（例如）/usr/lib/x86_64-linux-gnu/libz，它想知道它添加到程序中的任何尚未定义的引用是否具有libz导出的定义

如果这是真的，那么链接器将不会从libz和将它们添加到您的程序中；相反，它只会修改程序的代码从而：-

在运行时，系统程序加载器会将libz的副本加载到无论何时加载程序的副本，都可以执行与程序相同的过程。在运行时，每当程序引用libz，该引用使用中libz副本导出的定义相同的过程。

您的程序只想引用一个由libz导出的定义，即函数zlibVersion，在eg2.c中仅引用一次。如果链接器将该引用添加到程序中，然后找到定义由libz导出，引用被解析

但当您尝试链接程序时，如：

gcc -o eg2 -lz eg2.o

事件的顺序是错误的，其方式与示例1相同。在链接器找到-lz时，没有对任何内容的引用在节目中：他们都在eg2.o中，这还没有被看到。所以链接器决定它不适用于libz。当它达到eg2.o时，将其添加到程序中，然后对zlibVersion有未定义的引用，链接序列完成；该引用未解析，链接失败。

最后，示例2的pkg配置变体现在有了一个显而易见的解释。壳体膨胀后：

gcc -o eg2 $(pkg-config --libs zlib) eg2.o

变为：

gcc -o eg2 -lz eg2.o

这再次只是示例2。

我可以重复示例1中的问题，但不能重复示例2中的问题

联动装置：

gcc -o eg2 -lz eg2.o

对你来说很好！

（或者：在Fedora 23上，这种链接很好，但在Ubuntu 16.04上失败了）

这是因为链接工作的发行版是不配置其GCC工具链以根据需要链接共享库。

过去，类unix系统链接静态和共享是很正常的不同的规则。链接序列中的静态库已链接但是共享库是无条件链接的。

这种行为在链接时是经济的，因为链接器不必考虑程序是否需要共享库：如果是共享库，大多数链接中的大多数库都是共享库。但也有缺点：-

这在运行时是不经济的，因为它会导致共享库与程序一起加载，即使不需要它们。静态库和共享库的不同链接规则可能会令人困惑对于不熟练的程序员，他们可能不知道-lfo是否在他们的联系中将解析为/some/where/libfoo.a或/some/wwhere/libfoo.so，并且可能不理解共享库和静态库之间的区别无论如何

这种权衡导致了今天的分裂局面。一些发行版有更改了共享库的GCC链接规则，以便根据需要这一原则适用于所有图书馆。一些发行版沿用了旧版本方法

为什么即使同时编译和链接，我仍然会遇到这个问题？

如果我这样做：

$ gcc -o eg1 -I. -L. -lmy_lib eg1.c

当然，gcc必须首先编译eg1.c，然后链接生成的带有libmy_lib.a的对象文件，那么它怎么可能不知道该对象文件在进行链接时是否需要？

因为使用单个命令编译和链接不会更改连杆顺序。

当您运行上面的命令时，gcc发现您需要编译+链接。因此，在幕后，它生成一个编译命令，并运行然后生成一个链接命令并运行它，就像您运行了两个命令：

$ gcc -I. -c -o eg1.o eg1.c
$ gcc -o eg1 -L. -lmy_lib eg1.o

因此，如果运行这两个命令，链接就会失败。这个您在失败中注意到的唯一区别是gcc生成了编译+链接情况下的临时对象文件，因为您没有告诉它使用eg1.o.我们看到：

/tmp/ccQk1tvs.o: In function `main'

而不是：

eg1.o: In function `main':

另请参见

指定相互依赖的链接库的顺序错误

将相互依赖的库按错误的顺序排列只是一种方法在其中，您可以获取需要对即将到来的事物进行定义的文件在链接中晚于提供定义的文件。将库放在引用它们的对象文件是犯同样错误的另一种方式。

对的未定义引用WinMain@16或类似的“不寻常”main（）入口点引用（特别是对于visual studio）。

您可能错过了使用实际IDE选择正确的项目类型。IDE可能希望将例如Windows应用程序项目绑定到这样的入口点函数（如上面缺失的引用中所指定的），而不是通常使用的int main（int argc，char**argv）；签名

如果IDE支持普通控制台项目，您可能希望选择此项目类型，而不是windows应用程序项目。

---

下面是从真实世界问题中更详细地处理的案例1和案例2。

我正在构建一个共享/动态库。它在Linux和*BSD上运行，但在Mac OS X上，完全相同的编译和链接命令会产生未解决的引用错误。有什么好处？

Mac OS X在内部与Linux和*BSD非常不同。对象/可执行文件格式为

在Linux和*BSD上，当构建共享库时，默认情况下允许未解析的引用。期望它们在加载时能够满足主可执行文件和/或其他共享库的要求。如果在加载时无法解析这些符号，则共享库将无法加载。

在Mac OS X上，构建动态库时，默认情况下不允许未解析的引用。如果希望在加载时解析引用，则需要显式启用未解析的引用。这是使用未定义的dynamic_lookup链接器标志完成的。

在构建可加载插件时，允许未解析的引用非常有用。