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

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

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

---

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

已声明但未定义变量或函数。

典型的变量声明是

extern int x;

由于这只是一个声明，因此需要一个单独的定义。相应的定义如下：

int x;

例如，以下内容将生成错误：

extern int x;
int main()
{
    x = 0;
}
//int x; // uncomment this line for successful definition

类似的注释适用于函数。声明函数而不定义它会导致错误：

void foo(); // declaration only
int main()
{
   foo();
}
//void foo() {} //uncomment this line for successful definition

请注意，您实现的函数与您声明的函数完全匹配。例如，您可能有不匹配的简历限定符：

void foo(int& x);
int main()
{
   int x;
   foo(x);
}
void foo(const int& x) {} //different function, doesn't provide a definition
                          //for void foo(int& x)
                          

不匹配的其他示例包括

函数/变量在一个命名空间中声明，在另一个命名空间定义。函数/变量声明为类成员，定义为全局（反之亦然）。函数返回类型、参数编号和类型以及调用约定并不完全一致。

来自编译器的错误消息通常会给出已声明但从未定义的变量或函数的完整声明。将其与您提供的定义进行比较。确保每个细节都匹配。

如果所有其他操作都失败，请重新编译。

最近，我只需重新编译有问题的文件，就可以消除Visual Studio 2012中未解决的外部错误。当我重新构建时，错误消失了。

当两个（或多个）库具有循环依赖关系时，通常会发生这种情况。库A尝试使用B.lib中的符号，库B尝试使用A.lib中的字符。两者都不存在。当您尝试编译A时，链接步骤将失败，因为它找不到B.lib。将生成A.lib，但不会生成dll。然后编译B，这将成功并生成B.lib。重新编译A现在可以工作了，因为现在找到了B.lib。

函数或类方法在源文件中使用内联说明符定义。

例如：-

主.cpp

#include "gum.h"
#include "foo.h"

int main()
{
    gum();
    foo f;
    f.bar();
    return 0;
}

foo.h（1）

#pragma once

struct foo {
    void bar() const;
};

口香糖.h（1）

#pragma once

extern void gum();

foo.cpp（1）

#include "foo.h"
#include <iostream>

inline /* <- wrong! */ void foo::bar() const {
    std::cout << __PRETTY_FUNCTION__ << std::endl;
}

gum.cpp（1）

#include "gum.h"
#include <iostream>

inline /* <- wrong! */ void gum()
{
    std::cout << __PRETTY_FUNCTION__ << std::endl;
}

如果指定gum（类似地，foo:：bar）在其定义中是内联的，那么编译器将通过以下方式内联gum（如果它选择）：-

没有任何独特的口香糖定义，因此不发出任何符号，链接器可以通过该符号引用口香糖的定义，而是将所有对gum的调用替换为编译后的gum主体的内联副本。

因此，如果在源文件gum.cpp中内联定义gum，则编译为对象文件gum.o，其中所有对gum的调用都是内联的并且没有定义接头可以指代口香糖的符号。当你将gum.o与另一个对象文件（例如main.o）链接到程序中引用外部符号gum时，链接器无法解析这些参考文献。因此连杆失效：

编译：

g++ -c  main.cpp foo.cpp gum.cpp

链接：

$ g++ -o prog main.o foo.o gum.o
main.o: In function `main':
main.cpp:(.text+0x18): undefined reference to `gum()'
main.cpp:(.text+0x24): undefined reference to `foo::bar() const'
collect2: error: ld returned 1 exit status

如果编译器可以在调用gum的每个源文件中看到它的定义，则只能将gum定义为内联。这意味着它的内联定义需要存在于包含在每个源文件中的头文件中您可以在其中调用gum。做两件事之一：

要么不内联定义

从源文件定义中删除内联说明符：

foo.cpp（2）

#include "foo.h"
#include <iostream>

void foo::bar() const {
    std::cout << __PRETTY_FUNCTION__ << std::endl;
}

gum.cpp（2）

#include "gum.h"
#include <iostream>

void gum()
{
    std::cout << __PRETTY_FUNCTION__ << std::endl;
}

重新生成：

$ g++ -c  main.cpp foo.cpp gum.cpp
imk@imk-Inspiron-7559:~/develop/so/scrap1$ g++ -o prog main.o foo.o gum.o
imk@imk-Inspiron-7559:~/develop/so/scrap1$ ./prog
void gum()
void foo::bar() const

成功

或正确内联

头文件中的内联定义：

foo.h（2）

#pragma once
#include <iostream>

struct foo {
    void bar() const  { // In-class definition is implicitly inline
        std::cout << __PRETTY_FUNCTION__ << std::endl;
    }
};
// Alternatively...
#if 0
struct foo {
    void bar() const;
};
inline void foo::bar() const  {
    std::cout << __PRETTY_FUNCTION__ << std::endl;
}
#endif

口香糖.h（2）

#pragma once
#include <iostream>

inline void gum() {
    std::cout << __PRETTY_FUNCTION__ << std::endl;
}

现在我们不需要foo.cpp或gum.cpp：

$ g++ -c main.cpp
$ g++ -o prog main.o
$ ./prog
void gum()
void foo::bar() const

我的例子：

头文件

class GameCharacter : public GamePart
{
    private:
        static vector<GameCharacter*> characterList;
...
}

.cpp文件：

vector<GameCharacter*> characterList;

这产生了“未定义”加载程序错误，因为“characterList”被声明为静态成员变量，但被定义为全局变量。

我加上这个是因为——虽然其他人在一长串需要注意的事情中列出了这个案例——但这个列表并没有给出示例。这是一个更值得寻找的例子，尤其是在C++中。

修复方法是向全局变量添加限定以定义静态数据成员：

vector<GameCharacter*> GameCharacter::characterList;

同时保持收割台相同。

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

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

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

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

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